Apostila elementos de projeto de informática

ELEMENTOS DE PROJETOS DE INFORMÁTICA
EdiçÃo nº 1 - 2008
ROSEMARY FRANCISCO
Apoio Gestão e Execução Conteúdo e Tecnologia

Elementos de Projetos de Informática2
SOCIESC - Sociedade Educacional de Santa Catarina
Apresentação
Este livro didático contém a disciplina de Elementos de Projetos de Informá-
tica.
O conteúdo deste livro irá disponibilizar aos alunos do EAD os conceitos funda-
mentais sobre o processo de desenvolvimento de projetos de informática. Por meio
deste material, será possível conhecer as fases do processo de desenvolvimento de
software e as melhores práticas que possibilitam: identificar e analisar um problema,
modelar a solução deste problema e, também, como gerenciar todas as fases deste
processo durante a evolução de um projeto.
Para sua melhor compreensão, o livro está estruturado em quatro partes: na
primeira, apresentaremos os conceitos básicos sobre projetos de informática e os
dois principais elementos que serão utilizados durante o processo de desenvolvimen-
to de software; na segunda, as principais características do processo de desenvol-
vimento de software e os diagramas da UML mais utilizados durante o processo; na
terceira parte, demonstraremos os passos para iniciar o desenvolvimento de projetos
de software, mostrando as principais técnicas utilizadas para iniciar um projeto e fazer
o correto acompanhamento durante a evolução das fases de desenvolvimento; na
quarta e última parte do livro, desenvolveremos um estudo de caso que permitirá a
consolidação dos conhecimentos adquiridos nesta disciplina.
Lembre-se de que a sua passagem por esta disciplina será acompanhada tam-
bém pelo Sistema de Ensino Tupy Virtual, seja por correio postal, fax, telefone, e-mail
ou Ambiente Virtual de Aprendizagem. Entre sempre em contato conosco quando sur-
gir alguma dúvida ou dificuldade.
Toda a equipe terá a maior alegria em atendê-lo, pois seu crescimento intelec-
tual e profissional, nessa jornada, é o nosso maior objetivo.
Acredite no seu sucesso e bons momentos de estudo!
Equipe Tupy Virtual

Elementos de Projetos de Informática 3
SUMÁRIO
CARTA DA PROFESSORA......................................................................................... 4
CRONOGRAMA DE ESTUDOS.................................................................................. 6
PLANO DE ESTUDOS................................................................................................. 7
Aula 1 – Introdução a Projetos de Informática........................................................ 8
Aula 2 – Introdução a UML...................................................................................... 20
Aula 3 – Introdução a Ferramentas CASE............................................................. 34
Aula 4 – Conhecendo os principais diagramas UML............................................ 49
Aula 5 – Conhecendo o Processo de Desenvolvimento de Software................. 69
Aula 6 – Modelando Projetos de Software............................................................. 80
Aula 7 – Tendências do Processo de Engenharia de Software........................... 96
Aula 8 – Estudo de Caso: Modelando um Projeto de Software......................... 103
Referências..............................................................................................................112
Apêndice 1 – Revisão Paragima Orientação a Objetos.......................................113

Carta da Professora
Caro(a) aluno(a),
Nos próximos capítulos, terá início a caminhada rumo ao conhecimento dos
principais elementos para o desenvolvimento de projetos de informática, em especial,
os projetos de desenvolvimento de software. Para desenvolver um projeto de sof-
tware, assim como projetos de outras áreas de conhecimento, como engenharia civil,
por exemplo, é necessário que os profissionais envolvidos conheçam grande parte
das informações relacionadas ao projeto e, principalmente, compreendam qual é o
problema que deve ser resolvido. Porém, como um software é um objeto abstrato, o
resultado final não é palpável como uma casa ou um edifício, seu processo de desen-
volvimento é considerado complexo.
O processo de desenvolvimento de software tem sido aprimorado desde o iní-
cio da década de 1980 e, ainda hoje, há várias discussões e constantes grupos de
pesquisa para aperfeiçoamento de técnicas que possam contribuir com melhorias
para esse processo.
Com a evolução do paradigma da Orientação a Objetos, o processo de desen-
volvimento de software começou a se beneficiar de novas técnicas de modelagem de
software - como a linguagem UML - que surgiram para auxílio no desenvolvimento
e também para a minimização da complexidade que envolve o desenvolvimento de
sistemas de softwares. Essas técnicas vêm sendo utilizadas com bastante ênfase,
principalmente nas empresas denominadas: Fábricas de Software – empresas cujo
negócio é o desenvolvimento de projetos de software diversos para outras empresas,
independente do tipo de software.
Porém, não são somente as Fábricas de Software que utilizam as técnicas de
modelagem e desenvolvimento de software, todas as empresas que possuem em
sua estrutura uma área de desenvolvimento de projetos de software, também estão
fazendo uso dessas técnicas para garantir o sucesso da solução empregada para a
resolução dos problemas identificados.

Portanto, é muito importante que o profissional de informática conheça as
técnicas e saiba aplicá-las corretamente durante o desenvolvimento de projetos de
software. Assim, nosso objetivo maior, depois de percorrida esta caminhada, é co-
nhecermos os principais elementos que estarão inseridos em projetos de software e
também quais as melhores práticas para o desenvolvimento desses projetos.
Durante esta caminhada, conheceremos: a origem dos projetos de software, o
que é e quais os benefícios de utilizar a UML em projetos de software, conhecer o que
são as ferramentas CASE e como podemos utilizá-las em conjunto com a UML; como
é a estrutura do Processo de Engenharia de Software e quais suas principais caracte-
rísticas e, ao final, desenvolveremos um estudo de caso com o intuito de praticarmos
melhor o conhecimento adquirido.
Sendo assim, convido você para, juntos, agora virtualmente, vencer este novo
desafio!
Professora Rosemary Francisco

Cronograma de Estudos
Acompanhe no cronograma abaixo os conteúdos das aulas, e atualize as pos-
síveis datas de realização de aprendizagem e avaliações.
Semana Carga horária Aula Data/ Avaliação
1
4
Introdução a Projetos de
Informática _/_ a _/_
4 Introdução a UML
_/_ a _/_
8
Introdução a Ferramentas
CASE _/_ a _/_
2
8
Conhecendo os principais
diagramas da UML _/_ a _/_
8
Conhecendo o Processo de
desenvolvimento de Software _/_ a _/_
3
12
Modelando Projetos de
Software _/_ a _/_
4
Tendências do Processo de
Engenharia de Software _/_ a _/_
4 12
Estudo de Caso: Modelando um
Projeto de Software _/_ a _/_

Plano de Estudos
Ementa
Introdução a projetos de desenvolvimento de software; Visão geral da linguagem
UML; Principais Diagramas da Linguagem UML; Introdução a ferramentas CASE; In-
trodução ao Processo de Desenvolvimento de Software; Principais Características do
Processo de desenvolvimento de Software; Introdução às melhores práticas de mo-
delagem e desenvolvimento do software; Projetar, gerenciar e implementar sistemas
de Software.
Objetivos da Disciplina
• Geral
Capacitar o aluno com os conhecimentos básicos do processo de desenvolvimento
de software que permitirão aprender a: analisar, projetar e implementar sistemas de
software.
• Específicos
• Introduzir os conceitos básicos de projetos de software
• Apresentar a linguagem de modelagem padrão de mercado Unified Modeling Lan-
guage (UML) largamente utilizada para a Análise e Projeto de sistemas de software
• Apresentar um processo completo de desenvolvimento de software utilizável com a
linguagem UML
• Demonstrar as principais características das ferramentas CASE
• Instalar e configurar uma ferramenta CASE
• Apresentar técnicas e ferramentas básicas para análise, gerenciamento e implemen-
tação de projetos de software
• Desenvolver a modelagem de um estudo de caso para consolidar os conhecimentos
da disciplina
Carga Horária: 60 horas/aula.

Aula 1
INTRODUÇÃO A PROJETOS DE
INFORMÁTICA
Nesta aula você estudará os conceitos básicos de pro-
jetos de informática e Engenharia de Software e como
a Engenharia de Software poderá auxiliar no desenvolvimento e
manutenção de sistemas de software.
Bom estudo!
Objetivos da Aula
Ao final desta aula você deverá ser capaz de:
• Apontar as características de um projeto de informática;
• Identificar os conceitos básicos da Engenharia de Softwa-
re;
• Identificar os objetivos da Engenharia de Software.
Conteúdos da Aula

Acompanhe os conteúdos desta aula. Se você preferir, assi-
nale-os à medida em que for estudando.
• O Projeto de Informática;
• Conceitos Básicos de Engenharia de Software;
• Exercícios propostos.

1 O QUE É PROJETO DE INFORMÁTICA
Antes de compreendermos o que é um projeto de informática, é importante sa-
bermos a definição de projeto como um todo. De acordo com o Dicionário Aurélio, há
cinco significados para a palavra projeto:
1. Idéia que se forma de executar ou realizar
algo, no futuro; plano, intento, desígnio.
2. Empreendimento a ser realizado dentro de
determinado esquema: projeto administrativo;
projetos educacionais.
3. Redação ou esboço preparatório ou provi-
sório de um texto: projeto de estatuto; projeto
de tese.
4. Esboço ou risco de obra a se realizar; plano:
projeto de cenário.
5. Plano geral de edificação.
Analisando os significados indicados pelo Dicionário Aurélio, podemos então
compreender que um projeto, independente do tipo de aplicação, pode ser considera-
do como um planejamento, com menos ou mais detalhes, dependendo da sua aplica-
ção, que poderá auxiliar na execução e avaliação do resultado obtido ao final de sua
execução.
Ao analisarmos o contexto de nossas próprias vidas, podemos identificar vários
elementos que se assemelham aos “projetos”. Um exemplo simples que podemos
utilizar é o planejamento de uma viagem de turismo. Para realizarmos uma viagem
de turismo é necessário sabermos: o local destino da viagem, o custo dessa viagem,
a forma de transporte, a forma de hospedagem, a melhor época para realização da
viagem, entre outros. Além disso, ao planejar uma viagem de turismo, precisamos
saber quando poderemos realizá-la e também se temos condições financeiras para
realizá-la, lembrando sempre que uma viagem que dura um final de semana possui
um planejamento bem mais simples do que outra que dura em torno de 10 dias. Por-

tanto, independente do tipo de projeto que se deseja realizar, é muito importante saber
qual será a duração, em outras palavras, quando é o início e o fim da realização do
projeto.
Os projetos de informática possuem várias características que se assemelham
a um projeto de turismo, porém no projeto de informática – como é o caso do software
– o produto é abstrato, motivo pelo qual a elaboração e a condução desse tipo de pro-
jeto se torna muito mais complexo devido ao grande número de variáveis que podem
modificar a estrutura do projeto e, conseqüentemente, seu resultado final.
Neste módulo, focalizaremos principalmente a elabo-
ração e execução de projetos para desenvolvimento
de software, porém muitas técnicas que abordare-
mos poderão ser utilizadas em outros projetos tan-
to de informática, como um projeto de montagem de
uma rede de computadores, por exemplo, quanto de
outras áreas. Em alguns casos, alguns ajustes po-
dem ser necessários, mas em um contexto geral, a
parte de análise e detalhamento do projeto pode ser
disseminada para outros tipos de projetos.
1.2 PRINCIPAIS CARACTERÍSTICAS DE UM PROJETO
As principais características de um projeto são:
• Duração – tempo estimado para início e fim do projeto
• Custo – valor do projeto no total
• Planejamento – de que forma e com quais recursos será desenvolvido o
projeto.
• Qualidade – resultado obtido na finalização do projeto
A característica Planejamento, além de estar diretamente relacionada com Du-
ração e Custo, também irá refletir na Qualidade do projeto. Portanto, se o planejamen-
to não for desenvolvido de maneira eficiente, o sucesso do projeto estará automatica-
mente comprometido.

Fique sabendo
Atualmente, existem vários modelos que permitem auxiliar nas ta-
refas de planejamento e gerenciamento de projetos. Os modelos
mais populares são: PMBOK um guia de gerenciamento criado pelo
PMI - Project Manegement Institute – http://www.pmi.org/ ; Processo
Unificado - UP – criado pelos autores da linguagem UML - Grady Booch,
James Rumbaugh e Ivar Jacobson; MSF – Microsoft Solutions Framework; e, den-
tro dos conceitos de desenvolvimento Ágil: SCRUM, Extreme Programming, entre
outros.
1.3 RESULTADO DOS PROJETOS DE SOFTWARE
Desde 1994, o Standish Group - www.standishgroup.com - publica um estudo
intitulado de “Chaos Research” que consolida as informações de uma grande pesqui-
sa sobre sucessos e fracassos dos projetos de software. Nesse estudo, os resultados
dos projetos são classificados da seguinte maneira:
• Bem sucedidos - O projeto é finalizado no prazo, dentro do orçamento e
contendo todas as funcionalidades especificadas.
• Comprometidos - O projeto é finalizado e um software operacional é entre-
gue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além
disso, o software entregue possui menos funcionalidades do que o especifica-
do.
• Fracassados - O projeto é cancelado em algum momento durante o desen-
volvimento.
Veja na figura 1 o resultado do “Chaos Research” publicado até o ano de 2002.

Figura 1 – Resultado do Chaos Research até o ano de 2002
Analisando a figura 1, podemos observar que a quantidade de projetos consi-
derados Bem sucedidos aumentou consideravelmente desde 1994, quando apenas
16% dos projetos realizados eram bem sucedidos. A partir daí, esse número foi cres-
cendo e, em 2002, a quantidade de projetos bem sucedidos chegou a 34%.
De qualquer forma, podemos verificar que ainda é muito grande a quantidade
de projetos que não são bem sucedidos. Podemos verificar também que a grande
maioria dos projetos está na categoria dos comprometidos, tiveram problemas no
planejamento como custo além do esperado, ou ainda com uma duração muito maior
do que a estipulada.
De posse dessas informações, podemos concluir que é imprescindível aos pro-
fissionais de informática, em especial os desenvolvedores de software, a utilização
das melhores técnicas da Engenharia de Software para planejar e conduzir seus pro-
jetos, dessa forma, a garantia de projetos Bem Sucedidos será consideravelmente
maior.
2 O QUE É ENGENHARIA DE SOFTWARE
“A engenharia de software é um rebento da engenharia de sistemas e de hardware.
Ela abrange um conjunto de três elementos
fundamentais – métodos ferramentas e pro-
cedimentos – que possibilita ao gerente o
controle do processo de desenvolvimento de
Neste contexto podemos traduzir a pala-
vra rebento como uma junção/união en-
tre a engenharia de sistemas e de hardwa-
re. Com a união destas duas engenharias
surgiu a Engenharia de Software.

software e oferece ao profissional uma base para a construção de software de alta
qualidade produtivamente” (PRESSMAN, 1995, p. 31).
Analisando a definição de engenharia de software feita por Pressman, pode-
mos interpretá-la como um conjunto de métodos, ferramentas e técnicas que auxiliam
os profissionais no desenvolvimento dos projetos de software.
Mas...
Por que é necessária a utilização da Engenharia de Software nos projetos de
software?
Antes de responder esta questão, é importante analisarmos um pouco alguns
dados históricos a respeito do desenvolvimento de software.
Como já sabemos, a informática é uma ciência muito nova ainda, em relação a
outras ciências como medicina e direito, por exemplo, que já existem há alguns sécu-
los. Se relembrarmos os fatos históricos sobre a colonização do Brasil, veremos que,
naquela época, já existiam profissionais de medicina e de direito. A informática ainda
não completou um século de existência, o primeiro computador, o ENIAC, foi criado
em 1946.
Fique sabendo
O engenheiro John Presper Eckert e o físico John Mauchly proje-
taram o ENIAC: Eletronic Numeric Integrator And Calculator. Com
18000 válvulas, o ENIAC conseguia fazer 500 multiplicações por se-
gundo. Os custos para a manutenção e conservação do ENIAC eram
absurdos, pois dezenas a centenas de válvulas queimavam a cada hora e o
calor gerado por elas necessitava ser controlado por um complexo sistema de refri-
geração, além dos gastos elevadíssimos de energia elétrica. (WIKIPÉDIA)
Antes do ENIAC, já havia alguns recursos e Ferramentas
de informática, mas eram utilizadas somente por militares, que
fizeram uso dessa tenologia durante as duas grandes guerras
mundiais. Após a criação do ENIAC, a informática começou a
ser utilizada em outros cenários, como a indústria.
Na década de 50, deu-se início ao software, cuja evolu-

ção é possível verificar na figura 2.
Figura 2 – Evolução do Software
A primeira era da evolução do software teve início nos anos 1950 e se estendeu
até meados de 1965. Nesta era o software possuía as seguintes características:
• O desenvolvimento do software era feito sem nenhum tipo de planejamento,
até que os prazos começassem a se esgotar e os custos a subir descontrola-
damente;
• Grande parte dos softwares era desenvolvida utilizando conceito de orienta-
ção “batch” (atividades em lote);
• O hardware dedicava-se à execução de um único programa que, por sua vez,
dedicava-se a uma única aplicação específica;
• O software era projetado sob medida para cada aplicação e tinha distribuição
relativamente limitada;
• Geralmente o projeto do software era um processo implícito, realizado no cé-
rebro de alguém, e a documentação muitas vezes não existia.
De acordo com as características da primeira era da evolução do software,
podemos imaginar a complexidade que deveria ser desenvolver e depois realizar ma-
nutenções nos softwares desenvolvidos naquela época.
A segunda teve início em 1965 e se estendeu até 1975. Essa era foi marcada
pelas seguintes características:
• A multiprogramação e os sistemas multiusuários introduziram novos concei-
tos de interação homem-máquina;
• Teve início a utilização de técnicas interativas;
• Os avanços da armazenagem on-line levaram à primeira geração de sistemas
de gerenciamento de banco de dados;

• Começaram a surgir as “software houses“, empresas dedicadas exclusiva-
mente ao desenvolvimento de softwares;
• O software era desenvolvido para ampla distribuição num mercado interdisci-
plinar, início do conceito de produto de software;
• Os softwares eram geralmente programas desenvolvidos para mainframes e
minicomputadores;
• Surgimento da “manutenção de software”.
Na segunda era, podemos observar que houve um salto bem grande na evo-
lução do desenvolvimento de software. Foi nessa época que começaram a surgir as
primeiras idéias para o desenvolvimento de Sistemas Gerenciadores de Banco de
Dados, tecnologia muito utilizada atualmente no desenvolvimento de software.
Nessa época também começaram a surgir as empresas dedicadas exclusiva-
mente ao desenvolvimento de software e produtos de software, os chamados softwa-
re de prateleira.
A terceira era, que teve início em 1975 e foi até 1985, foi marcada pelas seguin-
tes características:
• As redes globais, as comunicações digitais de largura de banda elevada e a

crescente demanda de acesso “instantâneo” a dados exigem muito dos desen-
volvedores de software;
• Essa era foi caracterizada pelo advento e pelo generalizado uso de micropro-
cessadores, computadores pessoais e poderosas estações de trabalho “works-
tations” de mesa.
Para suprir as necessidades de mercado, nessa época, novos conceitos como
Sistemas Distribuídos e Inteligência Artificial começaram a surgir. Já tivemos
grandes avanços, mas como a aplicação desses conceitos é muito ampla, ainda hoje
existem muitos estudos e pesquisas sendo desenvolvidos.
Por fim, a quarta era, que iniciou em 1985, foi marcada pelas seguintes carac-
terísticas:
• As tecnologias orientadas a objetos começaram a ocupar o lugar das aborda-
gens mais convencionais para o desenvolvimento de software em muitas áreas
de aplicação;
• As técnicas de “quarta geração” para o desenvolvimento de software muda-
ram a maneira como alguns segmentos da comunidade de software constroem
programas de computador;
• Os sistemas especialistas e o software de inteligência artificial finalmente saí-
ram do laboratório para a aplicação prática em problemas do mundo real.

De acordo com as características da quarta era da evolução do software, pode-
mos perceber que vivemos uma nova era do desenvolvimento de software. Esta afir-
mação pode ser feita, pois os softwares desenvolvidos atualmente estão fortemente
marcados pelas seguintes características:
• A grande maioria dos softwares é desenvolvida com base na arquitetura clien-
te-servidor;
• O desenvolvimento de softwares para ambiente WEB está cada vez mais
comum;
• Introdução do conceito de serviços, pequenas aplicações específicas para um
determinado fim, está se propagando;
• Grande evolução dos sistemas gerenciadores de banco de dados, permitindo
a integração entre o banco de dados e sistemas disponíveis na internet;
• Preocupação com qualidade no desenvolvimento e planejamento dos softwa-
res fez surgir vários modelos e técnicas.
Assim, ao analisar a evolução no desenvolvimento de software, fica mais fácil
compreender a real necessidade da Engenharia de Software.
Vimos que, com o passar do tempo, muitos conceitos e tecnologias surgiram,
sempre com o intuito de abranger ou então suprir deficiências dos processos manti-
dos pelos softwares da época. No início, como o software era desenvolvido de forma
artesanal, seu custo e problemas por falta de planejamento era muito elevado.

Portanto, a Engenharia de Software nasceu justamente para
minimizar os problemas que ocorrem no processo de desenvolvi-
mento de software. Seu principal objetivo é melhorar a qualidade
dos softwares e aumentar a produtividade e satisfação dos profis-
sionais.
Síntese da Aula
Nesta aula estudamos:
• Introdução ao conceito de projeto de informática;
• Principais características de projetos de informática;
• Conceito e características de Engenharia de Software;
• A evolução do desenvolvimento de Software.
Exercícios Propostos
1) Assinale a alternativa correta. Para que um projeto de software seja bem su-
cedido, é imprescindível o cumprimento das seguintes características:
a) Prazo, Qualidade, Planejamento;
b) Custo, Prazo, Planejamento;
c) Custo, Prazo, Funcionalidades;
d) Funcionalidades, Prazo, Planejamento.
2) Selecione a alternativa correta. A característica de projeto que está diretamen-
te ligada às demais características e poderá impactar no seu sucesso é:
a) Duração

b) Qualidade
c) Prazo
d) Planejamento
2) Selecione a alternativa correta. É objetivo da Engenharia de Software:
a) Auxiliar somente no planejamento do projeto de software;
b) Auxiliar no desenvolvimento de todo o projeto de software, utilizando técnicas, fer-
ramentas e procedimentos;
c) Disponibilizar técnicas e ferramentas para a construção do software;
d) Disponibilizar ferramentas para o desenvolvimento de software.
3) Qual das alternativas abaixo é uma característica específica da era atual de
desenvolvimento de software?
a) Utilização de gerenciadores de banco de dados;
b) Utilização de inteligência artificial;
c) Utilização de arquitetura cliente-servidor;
d) Utilização de ambiente WEB.

Aula 2
INTRODUÇÃO A UML
Nesta segunda aula você estudará o que é modelagem
de software e qual a sua importância dentro de um
projeto de software. Também vamos estudar o que é a linguagem
UML, seu histórico, suas principais características e, por fim, como
esta linguagem pode auxiliar na modelagem de software.
Bom estudo!
Objetivos da Aula
Ao final desta aula, você deverá ser capaz de:
• Descrever a importância da modelagem;
• Identificar os conceitos básicos da UML;
• Descrever como a UML pode auxiliar na modelagem.
Conteúdos da Aula

• Modelagem de Software;
• Introdução a UML;
• UML e o Processo de Desenvolvimento de Software;

1 MODELAGEM DE SOFTWARE
Para que possamos compreender o que é e qual a importância da modelagem
de software, vamos primeiro analisar o que é o software, como surgiu e quais as suas
principais características.
De acordo com PRESSMAN (1995, p. 12), podemos definir didaticamente o
software das seguintes maneiras:
1. Instruções (programas de computador) que, quando executadas, produzem
a função e o desempenho desejados;
2. Estruturas de dados que possibilitam que os programas manipulem adequa-
damente a informação;
3. Documentos que descrevem a operação e o uso dos programas.
Se analisarmos novamente a figura 2 (pág. 14) – Evolução do Software – da
aula 1, veremos que o software surgiu com o objetivo principal de suporte às ativida-
des da informática, porém, naquela época, era visto como algo feito de forma artesa-
nal, sem grande importância e poucos possuíam o conhecimento de uma linguagem
de desenvolvimento. O importante mesmo, na época, era o hardware, que também
detinha grande parte dos custos dentro de
um projeto de informática ou mesmo auto-
mação de atividades.
Com o passar do tempo, as utilidades
adquiridas por meio da relação hardware e
software se tornaram mais expressivas e o
software começou a se tornar uma peça fundamental para os projetos de sistemas
de informação. Já não era mais possível desenvolver de forma artesanal, pois toda
responsabilidade em torno da manipulação dos dados ficou a cargo do software. É
justamente nesse momento, que a Engenharia de Software ganhou seu lugar de des-
taque.
Diferente do desenvolvimento de um hardware, que é um objeto físico, o sof-
tware é um objeto abstrato, em outras palavras, um objeto lógico. As principais carac-
A automação pode ser traduzida como
um procedimento que utiliza as tecnolo-
gias de sistemas de informação disponí-
veis para substituir atividades manuais
de mão-de-obra por equipamentos, siste-
mas e máquinas com o objetivo principal
de aumento na produtividade.

terísticas que diferenciam o software do hardware são:
• O sofware é desenvolvido ou projetado por engenharia, não manufaturado no
sentido clássico;
• O software não se desgasta;
• A maioria dos softwares é feita sob medida em vez de ser montada a partir de
componentes existentes.
A primeira característica citada por PRESSMAN indica que, diferente de um
produto de hardware – que também utiliza a engenharia durante o seu desenvolvi-
mento em um dado momento – esse objeto passa do modelo lógico – esboços e
desenhos da idéia feitos no papel – para algo palpável e manufaturado, construído em
um ambiente de produção, com auxílio de máquinas, equipamentos e pessoas desse
ambiente de produção. Já no desenvolvimento do software, todo o seu desenvolvi-
mento é concentrado com base na engenharia. Também há a fase de desenvolvimen-
to, qquando os programas e instruções são escritos, porém todas as fases de projeto
do software são baseadas em métodos e ferramentas da engenharia de software.
A segunda característica é realmente perceptível. O software jamais se desga-
ta, pode ficar ultrapassado, porém nunca diminuirá seu desempenho ou terá proble-
mas nas suas funcionalidades. Já o hardware, de acordo com o tempo de uso, poderá
mostrar falhas ou até parar de funcionar. As figuras 3 e 4 ilustram as diferenças na
ocorrência de falhas para o hardware e software.
Figura 3 – Curva de falhas para o Hardware

Figura 4 – Curva de Falhas para o Software
Podemos observar que a curva de falhas do hardware aumenta de acordo com
o passar do tempo. Já a curva de falhas do sofware, se considerarmos o modelo ide-
al, a tendência é que deixem de ocorrer com o tempo. Porém, como já discutimos nos
itens anteriores, problemas com o gerenciamento e o desenvolvimento do software
podem ocasionar falhas, quando se solicita uma alteração no software que já está
estável (modelo real).
A terceira característica apontada por PRESSMAN sugere que o software seja
sempre desenvolvido do início, ou seja, todos os programas e instruções são escri-
tos novamente a cada software, pois a característica dos softwares, muitas vezes, é
específica. Já com o hardware, componentes podem ser utilizados na sua produção,
reduzindo o tempo de produção e maximizando a qualidade do produto final. Nessa
característica, porém, a produção de software tem evoluído bastante com a utilização
da orientação a objetos, cuja programação torna possível “criar” componentes de sof-
tware que permitam sua reutilização nos próximos projetos de software. Essa é uma
tendência para o desenvolvimento de software.
De acordo com as características acima descritas, podemos interpretar o de-
senvolvimento de software como uma tarefa complexa que pode aumentar, dependen-
do da área de negócio onde o software irá atuar e também do seu tamanho, conforme
a quantidade de funcionalidades que irá dispor.
Assim, para minimizar essa complexidade e auxiliar na definição das funcionali-
dades do software, métodos, como a modelagem de sistemas, surgiram como suporte
para os projetos de software. A utilização de um modelo supre a necessidade de uma

representação idealizada de um software a ser desenvolvido. Por meio dos modelos,
será mais fácil compreender as funcionalidades e objetivo principal do sistema de sof-
tware, além de demonstrar a forma com que será desenvolvido.
Podemos comparar a modelagem de sistemas com a modelagem de outras
áreas da engenharia.
Um engenheiro de construção naval, por exemplo, desenvolve maquetes –
modelos de navios em tamanho reduzido – para representar o formato do navio e
analisar os detalhes da construção final do navio. Ao construir a maquete do navio,
o engenheiro naval poderá identificar vários problemas com o projeto inicial e corrigi-
los ainda nessa fase de modelo. Imagine: se o navio fosse construído direto, sem
que um modelo fosse desenvolvido anteriormente? Provavelmente muitos recursos
seriam disperçados ou, dependendo da grandeza do problema, o projeto poderia ser
inviabilizado.
Da mesma forma acontece com o desenvolvimento de sistemas de software.
Ao construirmos um modelo, temos a oportunidade de analisar com detalhes o funcio-
namento e as necessidades de recursos para o desenvolvimento do software e corri-
gir os possíveis problemas ainda na fase de modelo. Essa prática permitirá maximizar
a garantia de um software com maior qualidade.
1.2 Vantagens da Modelagem de Software
De acordo com BEZERRA (2002, p. 2) existem quatro razões para a utilização
da modelagem no desenvolvimento de software:
1. Gerenciamento da complexidade;
2. Comunicação entre as pessoas envolvidas;
3. Redução dos custos no desenvolvimento;
4. Predição do comportamento futuro do sistema.
Ao utilizar um modelo que simule o funcionamento do software, poderemos
comprender a real complexidade que envolverá o seu desenvolvimento. Com base
nesse conhecimento, será possível definir quais técnicas e procedimentos permitirão
gerenciar e reduzir a complexidade do software. Além disso, com o modelo, será

mais fácil discutir com uma equipe e identificar as melhores práticas e/ou ferramentas
necessárias para o seu desenvolvimento.
Defender uma idéia com um modelo já proposto também se torna muito mais
fácil e simples do que fazê-lo com uma idéia que ainda está no
pensamento. Isso porque, ao criar o modelo, muitas alterações e
melhorias poderão ser identificadas durante a sua construção. Ou
seja, já na criação do modelo, o próprio autor identifica problemas
que poderiam surgir e já faz as correções necessárias para apre-
sentar a idéia concreta aos demais membros da equipe.
A redução do custo, por sua vez, pode ser identificada conforme o tempo gas-
to no desenvolvimento de um software que não foi corretamente definido. Imagine
ir desenvolvendo um projeto apenas de acordo com o que “se acredita” ser a forma
correta. Ao apresentar a versão final do software para o usuário, é bem possível que
as seguintes frases sejam ditas: “Não era bem isso que eu queria” ou “Não foi isso que
eu pedi”. Assim, para evitar esse tipo de constrangimento, tanto para o desenvolvedor
quanto para o usuário, o ideal é construir um modelo dispendendo muito menos tempo
do que o desenvolvimento completo do sistema, e realizar a validação do modelo com
o usuário, antes do início da construção do sistema. Isso garantirá maior sucesso na
entrega do software.
Por fim, a predição do comportamento futuro do sistema pode ser considerada
como a principal razão para a construção do modelo de software, pois, com o modelo,
será possível mapear todo o funcionamento e também a interação entre as funciona-
lidades do software a ser desenvolvido.
1.3 Evolução da Modelagem de Software
A modelagem é uma prática que vem acompanhando a evolução do desenvol-
vimento de software. Por ser uma prática comum em outras engenharias, a modela-
gem também foi absorvida pela engenharia de software para dar suporte e permitir a
análise de detalhes do software, antes mesmo de sua produção.
BEZERRA (2002, p. 12) faz um breve resumo histórico da evolução da mode-
lagem de sistemas:

• Décadas de 1950/1960 – os sistemas de software eram bastante simples. O
desenvolvimento desses sistemas era feito de forma “ad-hoc”. Os sistemas
eram significativamente mais simples e, con-
seqüentemente, as técnicas de modelagem
eram mais simples: era a época dos fluxogra-
mas e dos diagramas de módulos.
• Década de 1970 – computadores mais avançados e acessíveis começaram
a surgir. Houve grande expansão do mercado computacional. Sistemas mais
complexos começavam a surgir. Por conseguinte, modelos mais robustos fo-
ram propostos. Surgem a Programação Estruturada e o Projeto Estruturado.
Os autores Larry Constantine e Edward Yourdon são grandes colaboradores
nessas técnicas.
• Década de 1980 – os computadores se tornaram ainda mais avançados e
baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou
a produção de sistemas de softwares mais complexos. A Análise Estruturada
surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter
Coad, Tom DeMarco, James Martin e Chris Gane.
• Início da década de 1990 – período em que surge um novo paradigma de
modelagem, a Análise Orientada a Objetos. Grandes colaboradores desse pa-
radigma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rum-
baugh, Grady Booch e Ivar Jacobson.
• Fim da década de 1990 – o paradigma da orientação a objetos atinge sua
maturidade. Os conceitos de padrões de projeto, frameworks, componentes
e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem
Unificada UML.
2 Introdução a UML
A UML (Unified Modeling Language) é uma linguagem-padrão para
a elaboração da estrutura de projetos de software. Pode ser
empregada para a visualização, a especificação, a construção
e a documentação de artefatos que façam uso de sistemas
Este termo significa “direto ao
assunto” ou “direto ao que inte-
ressa”.

complexos de software (BOOCH, 2005, p. 13).
A construção da UML teve muitos contribuintes, mas os principais foram: Grady
Booch James Rumbaugh e Ivar Jacobson. Três pesquisadores freqüentemente cha-
mados de “os três amigos” (BEZERRA, 2002, p. 13).
Como vimos no tópico 1.3, sobre a evolução da modelagem de sistemas, du-
rante a década de 1990, vários pesquisadores desenvolveram técnicas de modela-
gem com base na orientação a objetos. Os “três amigos”, que também estavam en-
volvidos em muitas dessas técnicas, procuraram unir as melhores propostas, realizar
melhorias e, por fim, criaram a UML.
Mas foi somente em 1997 que a UML foi aprovada como um padrão pelo órgão
internacional que rege os padrões na área de orientação a objetos, o OMG – Object
Management Group, http://www.omg.org
A partir de então, a UML tem tido grande aceitação pela comunidade de de-
senvolvedores de software. Atualmente, a linguagem está na sua segunda versão
– conhecida como UML 2 -, e continua em constante desenvolvimento. Empresas
como: HP, IBM, Oracle, Microsoft, entre tantas outras, tem dado especial atenção na
divulgação e evolução da linguagem.
2.2 Características da UML
A UML é uma linguagem visual para modelar sistemas orientados a objetos.
Significa que a UML é composta de elementos gráficos – visuais – que podem ser uti-
lizados na modelagem e, permitem representar os conceitos do paradigma da orien-
tação a objetos.
A UML, segundo Booch (2005, p.14), é uma linguagem destinada a:
• Visualizar;

• Especificar;
• Construir;
• Documentar
os artefatos de um sistema complexo de software.
Por meio dos elementos gráficos da UML, é possível visualizar, de forma mais
detalhada, como será o funcionamento do software e quais serão os objetos necessá-
rios para a construção do sofware.
Assim como a linguagem dispõe de elementos gráficos, que possibilitam me-
lhor visualização do funcionamento do software,
existem também artefatos que permitem detalhar
o funcionamento de forma textual. Existe um ditado
que diz: “Uma figura vale por mil palavras”, porém em alguns casos, pode-se utilizar
uma semântica para interpretar um símbolo UML.
Por ser uma linguagem-padrão, a UML tem sido absorvida por várias ferramen-
tas comerciais para dar suporte e facilitar o trabalho dos desenvolvedores durante a
construção do software. Algumas ferramentas permitem, por meio dos modelos UML,
a geração automática de partes do código-fonte do software. Em alguns casos, até
o inverso também é possível – prática conhecida como engenharia reversa -, onde a
ferramenta poderá gerar o modelo UML por meio de um código- fonte do software. A
prática de engenharia reversa, porém, não é muito aconselhável, pois o ideal é que do
modelo se parta para a construção final, e não o inverso, evitando problemas, alguns
já vistos nos tópicos anteriores, que podem surgir quando o software é construído por
completo sem ter um planejamento ou modelo a ser seguido. Em casos de atualiza-
ção do modelo, por exemplo, a engenharia reversa pode ser uma boa prática a ser
utilizada.
Um artefato é pode ser traduzido
como um documento de modela-
gem de orientação a objetos.

Fique sabendo
O termo “engenharia reversa” tem suas origens no mundo do
hardware. Uma empresa desmonta um hardware comercializado,
num esforço para entender os “segredos” de projeto e manufatura do
concorrente. A engenharia reversa para o software é muito semelhante,
porém, na maioria dos casos, o software que irá passar por este processo
é da própria empresa e tem como objetivo principal gerar a documentação de
partes do código que foram implementadas – muitas vezes direto no código, sem
desenvolvimento de um modelo específco. (PRESSMAN, 1995, p. 900)
Com base nos artefatos gerados por meio dos elementos da UML, é possível
também possuir uma documentação a respeito do funcionamento do software.
A UML abrange a documentação da arquitetura do sistema e de todos os seus deta-
lhes proporciona uma linguagem para a expressão de requisitos e para a realização
de testes. Também oferece uma linguagem para a modelagem das atividades de
planejamento do projeto e de gerenciamento de versões.
A UML foi criada especificamente para a área de modelagem de sistemas de
software, porém seus elementos e suas técnicas permitem sua utilização para mo-
delagem de outros projetos sistemas que não de software. Depois de sua aprovação
como um padrão, a linguagem, segundo Booch (2005, p.17), vem sendo empregada
em diversas áreas de conhecimento:
• Sistemas de informações corporativos;
• Serviços bancários e financeiros;
• Telecomunicações;
• Transportes;
• Defesa/espaço aéreo;
• Vendas de varejo;
• Eletrônica médica;
• Científicos;
• Serviços distribuídos baseados na WEB.
A UML é independente tanto de linguagens de programação quanto de proces-
so de desenvolvimento. Significa que pode ser utilizada para a modelagem de siste-

mas, não importando qual a linguagem de programação a ser utilizada na implemen-
tação do sistema, ou qual a forma – processo – de desenvolvimento adotado. Esse
é um fator importante para a utilização da UML, pois diferentes sistemas de software
requerem diferentes abordagens de desenvolvimento.
2.3 Visões de um Sistema
Como já dissemos, um sistema de software é algo complexo. Desta forma,
muitas vezes será necessário a criação de mais de um modelo, cada um com o foco
em uma determinada funcionalidade ou detalhe do sistema, para que seja possível
conceber a abrangência do software. Para isso, os autores da UML – os três amigos
– sugerem a utilização das: Visões do Sistema, que podem ser classificadas da se-
guinte forma:
• Visão de Caso de Uso: descreve o sistema de um ponto de vista externo,
como um conjunto de interações entre o sistema e os agentes externos ao
sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das
outras visões do sistema.
• Visão de Projeto: enfatiza as características do sistema que dão suporte,
tanto estrutural quanto comportamental, às funcionalidades externamente visí-
veis do sistema.
• Visão de Implementação: abrange o gerenciamento de versões do sistema
– controle de alterações -, construídas por meio do agrupamento de módulos –
componentes – e subsistemas.
• Visão de Implantação: corresponde à distribuição física do sistema em seus
subsistemas e à conexão entre essas partes.
• Visão de Processo: enfatiza as características de concorrência – paralelis-
mo -, sincronização e desempenho do sistema.
É claro que, dependendo das características do projeto, nem todas as visões
precisarão ser utilizadas. Sua utilização vai depender do tamanho do projeto e da
complexidade. Esta também é uma das grandes vantagens da UML, que permite ser
flexível de acordo com a necessidade de cada projeto. A interação entre as visões é

demonstrada na figura 5.
Figura 5 – Visões de um Sistema de Software
3 a UML e o processo de desenvolvimento de software
Desenvolver software é uma atividade complexa, que pode ser minimizada ou
maximizada, dependendo da área de negócio em que o software irá atuar; do hardwa-
re que irá utilizar; ou ainda, do tipo de procedimento que irá executar.
Vimos na primeira aula, segundo os dados do “Chaos Report”, o resultado das
pesquisas realizadas pelo Standish Group, que grande parte dos projetos de software
são considerados: fracassados – projetos que não são entregues – e comprometidos
– projetos que são entregues porém com os custos, prazos e funcionalidades compro-
metidas.
Portanto, todas as tentativas da engenharia de software que visam minimizar
essa complexidade no planejamento e desenvolvimento dos projetos, envolvem a de-
finição de processos de desenvolvimento de software.
Um processo de desenvolvimento de software – ou simplesmente, processo de
desenvolvimento – compreende todas as atividades necessárias para definir, desen-
volver, testar e manter um produto de software (BEZERRA, 2002, p. 19).
Os principais objetivos do processo de desenvolvimento de software são:
• Definição das atividades que serão executadas ao longo do projeto;
• Definição de quando, como e por quem as atividades serão executadas;
• Definição de pontos de controle para verificar o andamento do desenvolvi-
mento;

• Padronizar a forma de desenvolver software em uma organização.
A UML é uma grande aliada do processo de desenvolvimento. Por ser uma lin-
guagem padrão, permite que várias pessoas, com diferentes habilidades e envolvidas
no processo de desenvolvimento, possam compreender, analisar e sugerir melhorias
para o sistema de software, tudo isso por meio dos modelos definidos.
Veremos mais detalhes sobre o processo de desenvolvimento de software no
capítulo 5.
Síntese da Aula
Nesta aula estudamos,
• A definição de software e como surgiu;
• O que é e qual a importância da modelagem de sistemas de software;
• Os conceitos básicos da UML;
• O que é Processo de Desenvolvimento de Software e como a UML pode con-
tribuir para este processo.
1) Assinale a alternativa incorreta:
a) O software surgiu com o objetivo de auxiliar o hardware nas atividades de manipu-
lação da informação;
b) O software, assim como o hardware, pode ser desenvolvido de forma manufatura-
da;
c) O software é geralmente desenvolvido “sob medida”;
b) O software é um objeto lógico.

2) Assinale a alternativa correta:
a) A curva de falhas do software é considerada pequena no início do desenvolvimento,
porém tende a crescer com o passar do tempo;
b) A curva de falhas do hardware é considerada pequena no início do desenvolvimen-
to, porém tende a crescer com o passar do tempo;
c) A curva de falhas do hardware é considerada grande no início do desenvolvimento,
se estabiliza após a entrega do projeto, porém tende a crescer com o passar do tem-
po;
d) A curva de falhas do software é considerada grande no início do desenvolvimento,
se estabiliza após a entrega do projeto, porém tende a crescer com o passar do tem-
po;
3) Assinale a alternativa incorreta. As vantagens na utilização da modelagem
são:
a) Redução do prazo de desenvolvimento;
b) Gerenciamento da complexidade;
c) Visualização abrangente do funcionamento do sistema;
d) Redução do custo de desenvolvimento;
4) A UML surgiu na década de (única escolha):
a) 1960
b) 1970
c) 1980
d) 1990
5) Assinale a alternativa incorreta. Por meio da UML é possível:
a) Visualizar o funcionamento do sistema de software;
b) Escrever as instruções dos programas que irão compor o sistema de software;
c) Especificar o funcionamento do sistema de software de maneira textual;
d) Construir vários modelos que permitirão interpretar o funcionamento do sistema de
sofware.

Aula 3
INTRODUÇÃO A FERRAMENTA
CASE
Nesta aula você estudará sobre os conceitos básicos
que envolvem as ferramentas CASE e quais são os ti-
pos de ferramentas disponíveis para suporte ao desen-
volvimento de projetos de software. Também estudará a ferramenta
CASE que estaremos utilizando na disciplina que possibilitará a
criação de modelos para os projetos de software.
Boa aula!
Objetivos da Aula
• Identificar os principais conceitos da Ferramenta CASE;
• Enumerar os tipos existentes de Ferramenta CASE;
• Instalar a Ferramenta JUDE;
• Visualizar o ambiente de trabalho da Ferramenta JUDE.
Conteúdos da Aula

• Introdução à Ferramenta CASE;
• Utilizando Ferramenta CASE para Análise e Modelagem
de um Projeto;

1 INTRODUÇÃO A FERRAMENTAS CASE
A sigla CASE significa: Computer-Aided Software Engineering, em portu-
guês: Engenharia de Software auxiliada por computador. O significado do nome CASE
sugere a seguinte situação: desenvolver sistemas de software, utilizando as práticas
da Engenharia de Software e os recursos disponíveis por meio do computador.
Esses recursos, disponíveis por meio do computador, são classificados como
aplicativos – produtos de software, por exemplo – que foram desenvolvidos especifi-
camente para auxiliar nas tarefas de planejamento e desenvolvimento de projetos de
software.
Existem diversos aplicativos/ferramentas CASE disponíveis no mercado e com
finalidades diversas. Conforme Bezerra (2002, p.39), as principais características das
ferramentas CASE são:
• Criação de diagramas e manutenção da consistência entre os diagramas;
• Geração de código-fonte a partir de diagramas e geração de diagramas a
partir do código-fonte – engenharia reversa;
• Depuração de código-fonte: ferramentas que permitem encontrar erros de
lógica em partes de um programa;
8 Relatórios de testes: ferramentas que geram relatório informando sobre par-
tes de um programa que não foram testadas;
• Testes automáticos: ferramentas que realizam testes automaticamente no sis-
tema;
• Gerenciamento de versões: ferramentas que permitem gerenciar as diversas
versões dos artefatos de software gerados durante o ciclo de vida de um sis-
tema;
• Verificação de desempenho: averiguar o tempo de execução de módulos de
um sistema, assim como o tráfego de dados em sistemas em rede;
• Verificação de erros em tempo de execução;
• Gerenciamento de mudanças nos requisitos.
Além das características citadas por BEZERRA, existem também ferramentas

CASE que auxiliam no gerenciamento dos projetos de software. Esse tipo de ferra-
menta é utilizado pelos gerentes de projeto e permite: desenvolver cronogramas de
tarefas, definição de custos do projeto, acompanhamento de prazos e custos do pro-
jeto, alocação de profissionais para a execução das tarefas previstas no projeto, entre
outras.
1.2 Por que utilizar Ferramentas CASE em projetos de software
As ferramentas CASE surgiram com o objetivo principal de solucionar proble-
mas de qualidade e produtividade no desenvolvimento dos projetos de software. Para
compreendermos melhor essa questão, vamos utilizar a seguinte analogia: “Um me-
cânico possui em sua oficina inúmeras ferramentas em sua caixa de ferramentas que
permitem que seu trabalho seja desempenhado da melhor forma.” Do mesmo modo,
podemos interpretar as ferramentas CASE como ferramentas que podem ser adicio-
nadas à caixa de ferramentas do Engenheiro de Software e que permitirão desenvol-
ver o trabalho de forma mais produtiva. O aumento da produtividade irá, conseqüen-
temente, resultar em aumento da qualidade das atividades.
Outra vantagem que pode ser verificada na utilização das ferramentas CASE
é a melhoria das comunicações e documentações do projeto de software, devido à
maior possibilidade de precisão, consistência e representações claras de um sistema
de software.
A padronização de modelos e atividades também poderá ser adquirida por
meio das ferramentas CASE, porque algumas definições, em relação a metodologias,
técnicas e procedimentos, deverão ser empregadas no processo de desenvolvimento
de software, ao adotar uma ferramenta CASE como suporte no desenvolvimento de
projetos.
Mas a adoção de uma ou um conjunto de ferramentas CASE não é uma tarefa
fácil, devido ao custo – ainda que existam ferramentas gratuitas – e a complexidade
que uma ferramenta dessas pode trazer se o ambiente de trabalho e os profissionais
não estiverem capacitados para sua utilização.
Portanto, é imprescindível, antes da adoção dessas ferramentas, considerar os
seguintes itens:

• Custo de longo prazo da manutenção das ferramentas CASE (potencialmente
ao longo do ciclo de vida do sistema desenvolvido com a ferramenta);
• Lançamento freqüente de nova tecnologia;
• Custos contínuos para treinamento de novos funcionários e atualização dos
funcionários existentes já treinados;
• Reestruturação das ferramentas.
O sucesso ou falha na adoção das ferramentas CASE depende muito da habi-
lidade de uma organização para gerenciar custos de curto e longo prazo. As organi-
zações que têm tido cuidado com esses tipos de problemas no processo de adoção,
apresentam as melhores chances de sucesso.
O SEI - Software Engineering Institute - Instituto de Engenharia de Software
-, desenvolveu um processo de adoção de ferramentas CASE, cujo modelo define
seis estágios:
• Consciência;
• Comprometimento;
• Seleção;
• Implementação de testes;
• Estratégia de implementação;
• Rotinização
Os estágios sugeridos e a forma de aplicação podem ser observados na figura
6.
Figura 6 – Processo sugerido para adoção das ferramentas CA

1.3 Tipos de Ferramentas CASE
A engenharia de sofware auxiliada por computador pode ser tão simples quanto
uma única ferramenta que suporte uma atividade de engenharia de software específi-
ca ou tão complexa quanto um “ambiente” completo que abranja ferramentas, banco
de dados, pessoas, hardware, rede, sistemas operacionais, padrões e uma infinidade
de outros componentes (PRESSMAN, 1995, p. 947).
Um ambiente CASE, como vimos na definição de PRESSMAN, poderá abran-
ger muito mais do que uma única atividade no desenvolvimento de softwares, poderá
abranger todo o processo de desenvolvimento. A figura 7 ilustra a atuação do CASE
dentro de um ambiente integrado.
Figura 7 – Ambiente CASE
As ferramentas CASE podem ser classificadas por função, por seus papéis
como instrumentos para os gerentes e para o pessoal técnico pelo uso que têm nas
várias etapas do processo de engenharia de software, pela arquitetura de ambiente
– hardware e software – que as suporta ou até mesmo pela origem ou custo delas
(PRESSMAN, 1995, p. 951).
As ferramentas CASE podem ser classificadas da seguinte maneira:
• Ferramentas de planejamento de sistemas comerciais;
• Ferramentas de gerenciamento de projetos;
→ Ferramentas de planejamento de projetos;
→ Ferramentas de rastreamento dos requisitos;
→ Ferramentas de métricas e gerenciamento;
• Ferramentas de apoio;
→ Ferramentas de documentação;

→ Ferramentas de software básico;
→ Ferramentas de garantia da qualidade;
→ Ferramentas de banco de dados;
• Ferramentas de Análise e Projeto;
• Ferramentas de Programação;
• Ferramentas de Integração e Teste;
• Ferramentas de Prototipação;
• Ferramentas de Manutenção;
→ Ferramentas de Engenharia Reversa;
→ Ferramentas de Reengenharia;
• Ferramentas de Estrutura.
Nesta disciplina, utilizaremos a ferramenta CASE: JUDE que auxilia na fase de
análise e projeto do sistema de software.
2 UTILIZANDO FERRAMENTA CASE PARA ANÁLISE E PROJETO
As ferramentas de análise e projeto possibilitam que o engenheiro de software
crie um modelo do sistema que será construído (PRESSMAN, 1995, p. 958).
No modelo sugerido por PRESSMAN, será possível demonstrar informações
como: funcionalidades do sistema, componentes que serão utilizados pelas funcio-
nalidades, interação entre o usuário do sistema e as funcionalidades, forma como os
dados gerados pelo sistema serão armazenados, entre outros.
Na verdade, serão criados vários modelos, cada um com uma finalidade espe-
cífica, porém a união destes modelos irá representar o contexto geral e abrangência
do sistema de software que será desenvolvido.
2.1 O que é JUDE?
JUDE – Java and UML Developers’ Environment - é uma ferramenta CASE,
classificada como uma ferramenta de análise e projeto, que permite desenvolver a
modelagem de sistemas orientados a objetos, utilizando a linguagem padrão UML.
Ferramentas de prototipação são
ferramentas que permitem ao de-
senvolvedor criar um protótipo
– modelo – que irá representar
o layout das telas do sistema de
software.

Atualmente, a ferramenta possui três versões:
1. Community – versão gratuita, basta realizar um cadastro para ter acesso ao
arquivo de instalação;
2. Professional – é uma versão paga, pois disponibiliza mais recursos de inte-
gração com outras ferramentas;
3. Server – também uma versão paga que possui recursos como controle de
versão.
Nesta disciplina utilizaremos a versão Community da ferramenta. É uma versão
gratuita, mas possui todos os recursos necessários para desenvolvimento da mode-
lagem de projetos de software com base nos principais diagramas UML. Na aula 4,
veremos mais detalhes sobre os diagramas UML.
2.2 Instalando a ferramenta JUDE
Antes de iniciar o processo de instalação da ferramenta, será necessário aces-
sar o site e realizar um cadastro. Efetuando o cadastro, será habilitado um link para
acesso ao arquivo de instalação da ferramenta. Após o download do arquivo de ins-
talação, basta executá-lo e seguir as instruções de instalação.
Os passos para o processo de instalação são:
1. Acesse o site:
https://jude.change-vision.com/jude-web/product/community.html;
2. Clique no botão: [Download Jude Members Login], conforme mostra a figura 8;
Figura 8 – Site da ferramenta JUDE

3. Na tela seguinte, conforme mostra a figura 9, clique no botão: [New Registration]
para realizar o seu cadastro;
Figura 9 – Tela de acesso ao cadastro
4. Na próxima tela será solicitada a leitura do termo de contrato e o aceite dos termos
do contrato. Para dar continuidade, clique no botão: [I agree];
5. Em seguida, será mostrada a tela de cadastro (figura 10). Preencha todos os cam-
pos obrigatórios com atenção e, ao final, clique no botão para confirmação do cadas-
tro, botão: [Confirm];
Figura 10 – Tela de cadastro
6. Ao clicar no botão de confirmação, será mostrada uma tela para que você possa
validar os dados informados. Se os dados estiverem corretos, clique no botão: [Re-

gister] para efetivar o cadastro;
7. A confirmação do cadastro será encaminhada para o e-mail informado na tela de
cadastro. Para ter acesso ao arquivo de instalação da ferramenta, clique no botão:
[OK] da tela de confirmação de cadastro e informe o login e senha cadastrados;
8. Na tela seguinte, após a autenticação do seu login e senha, clique no botão: [Down-
load], conforme mostra a figura 11;
Figura 11 – Tela de acesso dos membros JUDE
9. Na próxima tela, serão disponibilizadas todas as versões do JUDE para download.
As versões pagas – Professional e Server – irão exigir o preenchimento da licença
após a instalação. Portanto, a versão que utilizaremos é a Community. Como o
JUDE é uma ferramenta desenvolvida em Java, é necessário que você possua em
seu computador a máquina virtual Java instalada, caso contrário, você poderá pegar
o arquivo de instalação do JUDE que vem com a máquina virtual embutida;
10. Se você já possui a máquina virtual Java instalada em seu computador, faça do-
wnload do primeiro arquivo listado na figura 12. Caso contrário, se você não possui a
máquina virtual Java instalada, faça o download do segundo arquivo da figura 12;

Figura 12 – Tela de acesso dos membros JUDE
11. Na próxima tela, clique no botão: [Download] para iniciar o processo de transferên-
cia do arquivo de instalação;
12. Finalização o download, clique duas vezes em cima do arquivo: jude-community-
5_2b1-setup.exe para iniciar a instalação. Selecione o idioma inglês e clique no bo-
tão: [Next], conforme mostra a figura 13;
Figura 13 – Tela 1 da instalação da ferramenta
13. Na tela seguinte, clique no botão: [Next], conforme mostra a figura 14;
Arquivo 1
Arquivo 1

14. Na tela seguinte, serão mostrados os termos de contrato. Selecione o aceite e
clique no botão: [Next], conforme mostra a figura 15;
15. Na tela seguinte, será solicitado o local para a instalação da ferramenta. Se prefe-
rir, deixe o local sugerido e clique no botão: [Next], conforme mostra a figura 16;
16. A próxima seguinte mostra o nome que será incluído no menu iniciar. Deixe o pa-
drão e clique no botão: [Next], conforme indica a figura 17;

17. A próxima tela seguinte questiona se você deseja: (1) incluir um ícone da ferra-
menta no desktop, (2) incluir um ícone no Quick Launch – acesso rápido -, (3) associar
os arquivos com extensão: .jude com a ferramenta. Deixe o padrão e clique no botão:
[Next], conforme mostra a figura 18;
18. Conforme mostra a figura 19, a próxima tela mostrará as informações seleciona-
das até agora. Valide as informações e clique no botão: [Install] para iniciar a instala-
ção da ferramenta.
19. A instalação será iniciada conforme mostra a figura 20. Aguarde até o final da
instalação.

20. Finalizada a instalação, será mostrada a tela conforme a figura 21. Clique no bo-
tão: [Finish] e a ferramenta JUDE será inicializada.
21. O ambiente de trabalho da ferramenta JUDE pode ser visualizado na figura 22.
Nas próximas aulas, veremos mais detalhes sobre a utilização da ferramenta.
Figura 22 – Área de trabalho da ferramenta JUDE

Síntese da Aula
• Os conceitos básicos sobre ferramentas CASE;
• Os tipos de ferramentas CASE existentes;
• O que é JUDE;
• Os passos para a instalação da ferramenta JUDE.

1) Assinale a alternativa incorreta. É característica das ferramentas CASE:
a) Definição das atividades do projeto;
b) Depuração do código-fonte;
c) Criação e manutenção de diagramas;
d) Realização de testes automáticos.
2) O principal objetivo das ferramentas CASE é (apenas uma alternativa está
correta):
a) Auxiliar na geração do código-fonte;
b) Aumentar a produtividade;
c) Solucionar os problemas de qualidade e produtividade;
d) Auxiliar na definição das tarefas.
3) Assinale a alternativa incorreta, antes de adotar um conjunto ou uma única
ferramenta CASE é aconselhável observar:
a) A linguagem de programação que é utilizada;
b) O custo da ferramenta CASE;

c) Os recursos disponibilizados pela ferramenta CASE;
d) O ambiente para a integração da ferramenta CASE.
4) O JUDE é uma ferramenta CASE classificada como (apenas uma alternativa
está correta):
a) Ferramenta para gerenciamento de projetos;
b) Ferramenta para apoio;
c) Ferramenta para análise e projeto;
d) Ferramenta para programação.

Aula 4
CONHECENDO OS PRINCIPAIS
DIAGRAMAS UML
Nesta quarta aula, vamos estudar quais são os ele-
mentos da UML e os principais diagramas utilizados
na modelagem de sistemas de software. Além disso,
veremos também a função de cada diagrama e sua representação
na modelagem de um sistema
de software.
Bom estudo!
Objetivos da Aula
• Enumerar os elementos da UML;
• Identificar os principais diagramas UML;
• Descrever o objetivo de cada diagrama.
Conteúdos da Aula

• Elementos da UML;
• Diagramas UML;

1 ELEMENTOS DA UML
Antes de introduzirmos os conceitos dos elementos da UML e seus principais
diagramas, é importante lembrar que a UML é baseada nos conceitos da orientação
a objetos, portanto, para melhor entendimento deste e dos próximos capítulos, é
imprescindível possuir o conhecimento básico do paradigma da orientação a objetos.
No apêndice 1 (final deste livro) está disponível um resumo com os principais concei-
tos da Orientação a Objetos.
A UML é composta dos seguintes elementos:
• Itens;
• Relacionamentos;
• Diagramas.
Os itens são os elementos utilizados nos diagramas para ilustrar com detalhes
o objetivo de um modelo. Os relacionamentos são, como o próprio nome sugere, os
relacionamentos entre os itens de um modelo e os diagramas, por sua vez, são os
elementos que agrupam e permitem a visualização dos itens e seus relacionamentos.
Um modelo de sistema de software pode conter um ou mais diagramas UML.
Os itens são classificados da seguinte forma:
• Itens estruturais;
• Itens comportamentais;
• Itens de agrupamentos;
• Itens anotacionais.
Os itens estruturais são considerados a parte estática dos modelos da UML.
São exemplos de itens estruturais:
• Classes – são descrições de conjuntos de objetos que compartilham os mes-
mos atributos, operações, relacionamentos e semântica;
• Interfaces – é uma coleção de operações que especificam serviços de uma
classe ou componente;
• Casos de Uso – descrição de seqüências de ações realizadas pelo sistema

que proporciona valor para um determinado ator.
Os itens comportamentais são considerados a parte dinâmica dos modelos
da UML. Representam comportamentos no tempo e no espaço. São exemplos de
itens comportamentais:
• Mensagens – mostram as interações entre os objetos, classes;
• Estados – definem os comportamentos que os objetos e classes podem as-
sumir ao longo do sistema;
• Ações – são as ações desempenhadas pelos objetos e classes do sistema.
Os itens de agrupamento são as partes organizacionais dos modelos UML.
Existe apenas um tipo principal de itens de agrupamento, os pacotes. Um pacote é
um mecanismo que permite a organização dos itens estruturais e comportamentais.
Por fim, os itens anotacionais são as partes explicativas dos modelos da UML. São
os comentários incluídos nos modelos e que permitem descrever, esclarecer e/ou
fazer alguma observação sobre qualquer elemento utilizado no modelo. A tabela 1
ilustra os elementos gráficos que representam os itens da UML.
Tabela 1 – Itens da UML
Classificação do Item Nome Figura
Estrutural Classe
Estrutural Interface
Ou

Estrutural Caso de Uso
Comportamental Mensagens
Comportamental Estados
Comportamental Ações / Atividades
Agrupamento Pacotes
Anotacional Notas
2 Diagramas UML
Um diagrama é apresentação gráfica de um conjunto de elementos da UML: os
itens e relacionamentos. Os diagramas são desenhados para permitir a visualização
de um sistema sob diferentes perspectivas ou visões do sistema. Retorne à aula 2
(figura 5) para observar as visões do sistema.
O diagrama UML irá representar uma visão parcial, em outras palavras, o mo-
delo dos elementos que compõe o sistema. Para cada sistema poderá ser desenhado
um ou mais diagramas. A quantidade de diagramas e a escolha pelo diagrama que
será utilizado vai sempre depender da área de atuação do sistema e da complexidade
do negócio. Um mesmo elemento UML, porém, poderá ser compartilhado em mais de
um diagrama, possibilitando melhor integração entre os modelos.
Atualmente, na versão dois, a UML disponibiliza treze diagramas que permitem
realizar qualquer tipo de combinação de itens e relacionamentos, além de possibilitar

a criação de diversas visões como modelo para os projetos de software. Não é neces-
sário utilizar os treze diagramas para todos os projetos de software desenvolvidos, a
premissa da escolha pelo diagrama e pelo nível de detalhamento dos modelos deve
partir da complexidade do software a ser construído. Quanto maior a complexidade,
maior deve ser o nível de detalhamento dos modelos.
Os treze diagramas da UML 2 são:
1. Diagrama de classes;
2. Diagrama de objetos;
3. Diagrama de componentes;
4. Diagrama de estruturas compostas;
5. Diagrama de casos de uso;
6. Diagrama de seqüências;
7. Diagrama de comunicações;
8. Diagrama de gráfico de estados;
9. Diagrama de atividades;
10. Diagrama de implantação;
11. Diagrama de pacote;
12. Diagrama de temporização;
13. Diagrama de visão geral da interação.
Nesta disciplina estudaremos apenas os principais diagramas UML, são eles:
1. Diagrama de classes;
2. Diagrama de casos de uso;
3. Diagrama de seqüências;
4. Diagrama de gráfico de estados;
5. Diagrama de atividades.
2.2 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 classes mostra um
conjunto de classes, interfaces e colaborações, além de seus relacionamentos.

Os diagramas de classes são compostos pelos seguintes elementos:
• Classes;
• Interfaces;
• Relacionamentos.
Esses são os elementos básicos para a composição de um diagrama de clas-
ses, porém, assim como nos demais diagramas, poderá conter: notas – itens anota-
cionais -, e também pacotes – itens de agrupamento.
Uma classe é a descrição de um conjunto de objetos que compartilham os mesmos
atributos, operações e relacionamentos.
A classe é utilizada em um diagrama de classes principalmente para classificar
os objetos identificados no universo do sistema - mundo real onde o sistema irá atu-
ar.
Exemplo de classes para um sistema de loja: cliente, pedido, produto, etc. Em
UML as classes são representadas por um retângulo dividido em três compartimentos:
nome da classe, atributos e operações. A figura 23 ilustra o formato de uma classe.
Figura 23 – Formato de uma classe
Os relacionamentos exibidos em um diagrama de classes têm como objetivo
ligar as classes e interfaces entre si, criando relações entre essas entidades. O rela-
cionamento é representado como um caminho, em que cada relacionamento possui
linhas diferentes, para melhor visualização. Há três tipos de relacionamentos na UML.
A tabela 2 demonstra quais são os tipos de relacionamentos existentes, a função de
cada relacionamento e seu elemento gráfico de representação.

Tabela 2 – Tipos de Relacionamentos
Nome Função Representação
Dependência
Relacionamento entre dois itens,
a alteração no item independente
pode afetar a semântica – funcio-
namento – do item dependente.
Elemento gráfico: seta aberta tracejada Exem-
plo:
Notação:
• A classe Dependente depende estruturalmente
da classe Independente.
Associação
Relacionamento estrutural entre
classes que descrevem um con-
junto de ligações, em que as liga-
ções são conexões entre objetos
que são instâncias das classes. A
agregação é um tipo especial de
associação, representando um
relacionamento estrutural entre o
todo e suas partes.
Elemento gráfico: linha simples
Exemplo:
Notação:
• Um departamento possui um ou mais funcioná-
rios na sua hierarquia.
Generaliza-
ção
Relacionamento de um elemento
mais geral e outro mais especí-
fico. Os objetos da classe-filha
podem ser utilizados em qualquer
lugar onde a classe-mãe ocorra,
mas não o contrário.
Elemento gráfico: seta fechada
Exemplo:
Notação:
• A classe: Atleta é a classe-mãe.
• As classes: Nadador e Tenista herdam a estru-
tura – atributos e operações – da classe Atleta.
Classes Asso-
ciativas
São classes ligadas a associa-
ções, em vez de estarem liga-
das a outras classes. Esse tipo
de classe normalmente aparece
quando duas ou mais classes
estão associadas e é necessário
manter informações sobre asso-
ciação.
Elemento gráfico: classe ligada a uma associa-
ção por uma linha tracejada
Exemplo:
Classe associativa = Emprego

Os relacionamentos do tipo: Associação possuem ainda algumas caracterís-
ticas que permitem um detalhamento maior no relacionamento entre duas classes.
Estas características estão descritas na tabela 3.
Tabela 3 – Características da Associação
Caracterís-
tica
Função Representação
Nome
Uma associação pode ter um
nome, que pode ser utilizado para
descrever a natureza do relacio-
namento.
Papel
Quando uma classe está em uma
associação, possui um papel es-
pecífico neste relacionamento.
Multiplicidade
É importante determinar a quan-
tidade (multiplicidade) de objetos
que podem ser conectados pela
instância de uma conexão. A ta-
bela 4 ilustra a simbologia para re-
presentar as multiplicidades.
Agregação
É um tipo especial de associação
que ilustra a associação todo/par-
te. Toda ação realizada sobre a
classe todo afetará as classes
partes.
Composição
A composição é um tipo especial
de agregação - agregação por va-
lor. Semanticamente equivalente
a um atributo.
A remoção do todo implica na re-
moção das partes e o acesso às
partes é restrito ao todo. Significa
que as classes/objetos indicadas
como “partes” de uma composi-
ção não estarão acessíveis ex-
ternamente, somente por meio da
classe/objeto “todo”.
Classe Pessoa
Classe Pessoa depois de utilizar composição

Tabela 4 – Simbologia para representar multiplicidades
Nome Simbologia
Apenas um 1
Zero ou Muitos 0..*
Um ou Muitos 1..*
Zero ou um 0..1
Os diagramas de classes são utilizados para
fazer a modelagem da visão estática de um sis-
tema. Essa visão oferece principalmente suporte
para os requisitos funcionais de um sistema – os
serviços que o sistema deverá fornecer aos usuários finais (BOOCH, 2005, p. 109).
As principais características dos diagramas de classes são:
• Representar os dados e funções tratados pelo sistema;
• Representar a forma como os dados serão armazenados de acordo com a
orientação a objetos – classes e objetos;
A figura 24 ilustra um exemplo de diagrama de classes de um sistema.
Figura 24 – Exemplo de diagrama de classes
Os requisitos funcionais e não-
funcionais serão discutidos com
mais detalhes nos capítulos 5 e
6.

2.3 Diagrama de casos de uso
Por meio do diagrama de casos de uso, é possível modelar os aspectos dinâ-
micos de um sistema de software. Os diagramas de caso de uso têm um papel im-
portante na modelagem do comportamento de um sistema, por meio dele é possível
identificar de forma visual as funcionalidades do sistema e a interação destas funcio-
nalidades com o usuário final.
Por utilizar uma representação gráfica simples e uma linguagem natural, o dia-
grama de casos de uso facilita a comunicação entre desenvolvedores e usuários. É
um diagrama bem importante, pois direciona as tarefas posteriores do ciclo de vida do
sistema de software.
Os diagramas de caso de uso são compostos pelos seguintes elementos da
UML:
• Fronteira do Sistema ou Assunto;
• Casos de Uso;
• Atores;
• Relacionamentos.
Assim como nos demais diagramas UML, o diagrama de casos de uso também
pode conter elementos como: notas e pacotes.
A fronteira do sistema ou assunto é exibido como um retângulo que agrupa os
casos de uso e seus relacionamentos com os atores e demais casos de uso.
Um caso de uso é a especificação de uma seqüência de interações entre o sis-
tema e os agentes externos que utilizam o sistema. Um caso de uso deve definir o uso
de uma parte da funcionalidade do sistema, sem a necessidade de revelar a estrutura
e o comportamento interno desse sistema.
O caso de uso pode ser representado graficamente em um diagrama de casos
de uso, ou então, detalhadamente em um formato textual. A UML não define o formato
e o grau de abstração a serem utilizados na descrição de um caso de uso, porém exis-
tem alguns modelos que já estão popularizados entre a comunidade UML. A tabela 5
demonstra um dos modelos utilizados para a definição textual dos casos de uso de um
sistema.

Tabela 5 – Documentação de Caso de Uso
Caso de Uso: Visualizar Avaliações
Sumário:
Aluno visualiza avaliação que recebeu – notas e freqüência – nas turmas
de um semestre letivo.
Ator Primário: Aluno
Ator Secundário: Professor
Pré-Condições: O aluno está identificado pelo sistema.
Fluxo Principal:
1. O aluno solicita a visualização das avaliações para as disciplinas em
que participou.
2. O sistema exibe os semestres letivos nos quais o aluno se inscreveu
em pelo menos uma disciplina.
3. O aluno seleciona os semestres letivos cujas avaliações deseja visu-
alizar.
4. O sistema exibe uma lista de avaliações agrupadas por semestres
letivos selecionados e por turma.
5. O aluno visualiza as avaliações e o caso de uso termina.
Fluxo de Exceção (2):
Aluno sem inscrição
1. Não há semestre letivo no qual o aluno tenha participado em alguma
disciplina.
2. O sistema reporta o fato e o caso de uso termina.
Pós-Condições: O aluno obteve as avaliações que desejava visualizar.
Fonte: BEZERRA, 2002, p. 82
A tabela 5 ilustra, de maneira geral, um modelo que pode ser utilizado para
a documentação de casos de uso, mas como a UML não define um formato para
a documentação textual, é importante conhecer a função de cada item utilizado na
documentação exemplo e definir quais são os itens utilizados em seus projetos de
software.
A função de cada item, segundo Bezerra (2002, p. 66), pode ser identificada do
seguinte modo:
• Nome – é o nome do caso de uso. Cada caso de uso deve possuir um nome
único que também deverá aparecer no diagrama de casos de uso.
• Sumário – uma pequena descrição do caso de uso, funcionalidade. Deve ser
breve e possuir no máximo duas frases.
• Ator Primário – o nome do ator que inicia o caso de uso.
• Ator Secundário – os nomes dos demais atores participantes do caso de
uso, se existirem.
• Pré-Condições – define as hipóteses que são assumidas como verdadeiras

para que o caso de uso tenha início.
• Fluxo Principal – corresponde à descrição da seqüência de passos do fluxo
principal do caso de uso, funcionalidade.
• Fluxos Alternativos – podem ser utilizados para descrever o que acontece
quando o ator faz uma escolha alternativa, diferente da descrita no fluxo prin-
cipal, para alcançar o seu objetivo. Esses fluxos podem ser utlizados também
para descrever situações de escolha exclusivas entre si – em que há diversas
alternativas e somente uma deve ser realizada.
• Fluxos de Exceção – correspondem à descrição das situações de exceção,
que descrevem o que acontece quando algo inesperado ocorre na interação
entre ator e caso de uso – por exemplo, quando um usuário realiza alguma
ação inválida.
• Pós-Condições – descreve o estado que o sistema alcança após o caso de
uso ter sido realizado com sucesso.
Os atores podem ser considerados como qualquer elemento externo que inte-
rage com o sistema. O termo “externo” indica que atores não fazem parte do sistema.
E o termo “interage” significa que um ator troca - envia e/ou recebe - informações com
o sistema.
Os atores podem ser classificados da seguinte forma:
• Pessoas – Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc.;
• Organizações – Empresa Fornecedora, Agência de Impostos, Administrado-
ra de Cartões, etc.;
• Outros Sistemas – Sistema de Cobrança, Sistema de Estoque de Produtos,
etc.
• Equipamentos – Leitor de Código de Barras, Sensor, etc.
Cada ator representa um papel em relação ao sistema. Um ator pode participar
de muitos casos de uso e um caso de uso também pode envolver vários atores: primá-
rios e secundários. O ator primário é aquele que inicia uma seqüência de interações
de um caso de uso; o secundário é aquele que supervisiona, opera, mantém ou auxilia
na utilização do sistema.

A comunicação ou interação entre as funcionalidades do sistema – casos de
uso – e os usuários do sistema – atores – é feita por meio dos relacionamentos. Os
tipos de relacionamentos disponíveis para os diagramas de caso de uso são:
• Comunicação – mais comumente utilizado. Faz a troca de informações entre
o ator e o caso de uso.
• Inclusão – disponível somente entre casos de uso. Utilizado quando dois ou
mais casos de uso incluem uma seqüência comum de interações.
• Extensão – é utilizado para modelar situações em que diferentes seqüências
de interações podem ser inseridas em um caso de uso. Cada uma dessas se-
qüências diferentes representa um comportamento opcional, que só ocorre sob
certas condições ou dependendo da escolha do ator.
• Generalização – é o mesmo conceito utilizado para as classes. Permite que
um caso de uso (ou um ator) herde características de um caso de uso (ou ator)
mais genérico.
A tabela 6 ilustra os elementos gráficos utilizados em um diagrama de casos de
uso.
Tabela 6 – Elementos gráficos do diagrama de casos de uso
Nome Representação
Fronteira do Sistema
Elemento gráfico: retângulo que agrupa os ca-
sos de uso e os relacionamentos
Ator
Elemento gráfico: boneco palito
Caso de Uso
Elemento gráfico: elipse

Relacionamento de Comunicação
Elemento gráfico: linha simples
Relacionamento de Inclusão – somente entre ca-
sos de uso
Elemento gráfico: seta tracejada com estereóti-
po: <<include>>
Relacionamento de Extensão – somente entre
casos de uso
Elemento gráfico: seta tracejada com estereóti-
po: <<extend>>
Relacionamento de Generalização
Elemento gráfico: seta fechada
A figura 25 ilustra um exemplo de diagrama de casos de uso.
Figura 25 – Diagrama de Casos de Uso

2.4 Diagrama de seqüência
O diagrama de seqüência faz parte dos diagramas da UML classificados como
diagramas de interação. Os diagramas de interação representam como o sistema age
internamente – comportamento dos objetos, troca de mensagens entre os objetos –
para que um ator atinja seu objetivo na realização de um caso de uso. A modelagem
de um sistema de software geralmente contém diversos diagramas de interação.
O diagrama de seqüência dá ênfase na ordem temporal das mensagens tro-
cadas entre os objetos do sistema de software. Sua função é ilustrar a seqüência do
envio das mensagens entre os objetos no decorrer do tempo.
Assim como os outros diagramas da UML, o diagrama de seqüência possui
um conjunto de elementos gráficos. A figura 26 ilustra um exemplo de diagrama de
seqüência e os seus elementos gráficos.
Figura 26 – Exemplo de diagrama de seqüência
De acordo com a figura 26, podemos verificar que o diagrama de seqüência,
assim como os demais diagramas, compartilham elementos gráficos. No caso do
diagrama de seqüência os elementos que podem ser compartilhados entre os demais
diagramas são: atores, objetos e classes.
Os elementos gráficos que são específicos deste diagrama são:
• Focos de controle – representa o tempo em que o objeto realiza uma ação.
O topo do foco de controle coincide com o recebimento de uma mensagem e
a parte de baixo coincide com a finalização de uma operação realizada pelo

objeto em questão;
• Linha da vida – representa a vida do objeto;
• Mensagem – é a troca de informação entre os objetos. Por meio de uma
mensagem, um objeto faz a chamada da operação de outro objeto.
2.5 Diagrama de gráfico de estados
Os diagramas de interação permitem modelar o funcionamento interno de um
sistema, detalhando a interação dos objetos – troca de mensagens – e a realização
das operações no decorrer do tempo. O diagrama de gráfico de estados, por sua vez,
tem como objetivo demonstrar o funcionamento interno de apenas um objeto. Nesse
diagrama é possível ilustrar as ações que um objeto pode sofrer durante o seu período
de vida no sistema e quais os estados que irá assumir após a realização de cada uma
dessas ações.
Um estado pode ser interpretado como uma situação na vida de um objeto du-
rante a qual ele satisfaz alguma condição ou realiza alguma atividade. Cada estado
de um objeto é normalmente determinado pelos valores dos seus atributos e/ou pelas
suas ligações com outros objetos. Exemplos: (1) o atributo reservado deste objeto
livro tem valor verdadeiro; (2) uma conta bancária passa para o vermelho quando o
seu saldo – atributo do objeto conta bancária – fica negativo.
A figura 27 ilustra um exemplo de diagrama de estados para o objeto Conta-
Bancaria.
Figura 27 – Exemplo de diagrama de estados

Os elementos gráficos do diagrama de estados estão ilustrados na tabela 7.
Tabela 7 – Elementos gráficos do diagrama de estados
Estado inicial do objeto
Elemento gráfico: círculo preenchido
Estado final do objeto
Elemento gráfico: círculo elipsado
Estado do objeto
Elemento gráfico: retângulo arredondado
Eventos / Ações – um evento é algo que aconte-
ce em algum ponto do tempo e pode modificar o
estado do objeto. Uma ação é uma operação que
pode ser realizada pelo próprio objeto.
Elemento gráfico: seta
2.6 Diagrama de atividades
Um diagrama de atividade é essencialmente um gráfixo de fluxo, que exibe o
fluxo de controle de uma atividade para outra. Ao contrário de um gráfico de fluxo
tradicional, um diagrama de atividades mostra a concorrência, bem como as ramifica-
ções de controle.
Os diagramas de atividade são utilizados para fazer a modelagem de aspectos
dinâmicos do sistema que envolve a modelagem das etapas seqüenciais – e possivel-
mente concorrentes – em um processo do sistema de software.
O diagrama de atividades irá representar os estados de uma atividade do sis-
tema de software em formato de fluxo de dados.
A figura 28 ilustra um exemplo de diagrama de atividade.

Figura 28 – Exemplo de diagrama de atividades
Os elementos gráficos do diagrama de estados estão ilustrados na tabela 8.
Tabela 8 – Elementos gráficos do diagrama de atividades
Estado inicial da atividade
Elemento gráfico: círculo preenchido
Estado final da atividade
Elemento gráfico: círculo elipsado
Atores envolvidos na atividade
Elemento gráfico: raias de natação
Ação dos atores nas atividades
Elemento gráfico: retângulo arredondado

Decisão
Elemento gráfico: losango
Transição das Ações Elemento gráfico: seta
Síntese da Aula
1) A classificação dos elementos da UML;
2) Os diagramas da UML 2;
3) Os principais diagramas UML utilizados na modelagem de sistemas de sof-
tware;
4) As características, objetivos e representação de cada um destes diagra-
mas.
1) Complete a frase com uma das alternativas abaixo: As classes são elementos
classificados como ..................... da UML.
a) Itens estruturais
b) Itens comportamentais
c) Itens de agrupamento
d) Itens anotacionais

2) O diagrama UML que representa o funcionamento interno de um sistema de
software é:
a) Diagrama de Classes
b) Diagrama de Casos de Uso
c) Diagrama de Atividades
d) Diagrama de Seqüência
3) Assinale a alternativa incorreta. O ator é um elemento que pode ser comparti-
lhado entre os seguintes diagramas:
a) Diagrama de Seqüência
b) Diagrama de Estados
c) Diagrama de Atividades
d) Diagrama de Casos de Uso
4) O relacionamento de comunicação é um relacionamento exclusivo do diagra-
ma de:
a) Classes
b) Casos de Uso
c) Atividades
d) Seqüência

Aula 5
CONHECENDO O PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
Nesta quinta aula você estudará os conceitos básicos
sobre o processo de desenvolvimento de software;
analisará o que é um processo de desenvolvimento de
software,quais as atividades desempenhadas no processo, quais
os padrões existentes e, por fim, alguns dos principais modelos de
processos disponíveis.
Bons Estudos!
Objetivos da Aula
• Identificar os conceitos básicos do processo de desenvol-
vimento de software;
• Enumerar as atividades do processo;
• Descrever os padrões de processo existentes;
• Analisar os modelos de processo disponíveis.
Conteúdos da Aula

• Introdução ao Processo de Desenvolvimento de Software;
• Conhecendo os Modelos do Processo;
• Exercícios Propostos.

1 INTRODUÇÃO AO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Um Processo de desenvolvimento de software pode ser considerado como um con-
junto de atividades que têm como resultado final um produto de software.
Esse conceito é um dos itens estudados pela Engenharia de Software e é um
dos principais mecanismos que permite alcançar as características de sucesso para
os projetos de software: cumprimento de prazo, custo, planejamento e qualidade no
resultado final.
O processo de desenvolvimento de software surgiu com o objetivo de resolver a
chamada: “Crise de Software”.
Fique sabendo
A crise do software foi um termo utilizado nos anos 70, quando
a engenharia de software era praticamente inexistente. O termo
expressava as dificuldades do desenvolvimento de software frente
ao rápido crescimento da demanda por software, da complexidade dos
problemas a serem resolvidos e da inexistência de técnicas estabelecidas para
o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem
ser validados.
As causas da crise do software estão ligadas à complexidade do processo de
software e à relativa imaturidade da engenharia de software como profissão. A crise
se manifesta de várias formas:
• Projetos estourando o orçamento;
• Projetos estourando o prazo;
• Software de baixa qualidade;
• Software muitas vezes não atingia os requisitos;
• Projetos ingerenciáveis e o código difícil de manter;
A maior parte dos projetos continua com esses problemas ainda na atualidade,
então pode-se dizer que a crise continua vigente ainda na atualidade.

1.2 Atividades do Processo
O processo de desenvolvimento de software pode ser dividido em sete ativida-
des:
1. Análise de requisitos de software – a extração dos requisitos de um dese-
jado produto de software é a primeira tarefa na sua criação. Embora o cliente,
provavelmente, acredite saber o que o software deva fazer, essa tarefa requer
habilidade e experiência em engenharia de software para reconhecer os requi-
sitos em um sistema de software complexo.
2. Especificação – a especificação é a tarefa de descrever precisamente o
software que será desenvolvido. Nessa atividade será elaborada grande parte
dos diagramas UML.
3. Arquitetura de Software – a arquitetura de um sistema de software faz uma
representação abstrata do sistema. Por meio das tarefas realizadas nessa ati-
vidade, será possível identificar se o sistema de software a ser desenvolvido
está de acordo com os requisitos pré-definidos. A etapa da arquitetura também
direciona as interfaces entre os sistemas de software e outros produtos de sof-
tware, como também com o hardware básico ou com o sistema operacional.
4. Implementação (ou codificação) – é a atividade responsável pelo desen-
volvimento do projeto do software efetivamente. É nessa atividade que o sof-
tware começará a ser construído e codificado por meio de linguagens de pro-
gramação e outras tecnologias pré-definidas nas atividades de Especificação
e Arquitetura de Software.
5. Teste – atividade que desenvolve os testes das funcionalidades do software.
Os testes serão sempre baseados nos artefatos e modelos resultantes das ati-
vidade de Especificação e Arquitetura de Software. Caso uma funcionalidade
não esteja de acordo com sua definição, deverá ser reescrita. Existem vários
métodos que auxiliam no controle do desenvolvimento e testes das funcionali-
dades.
6. Documentação – atividade que se refere à documentação do projeto inter-
no do software para propósitos de futuras manutenções e aprimoramentos. As
documentações mais importantes são das interfaces externas. Grande parte

dessa documentação já foi gerada nas atividades anteriores, principalmente
nas atividades de Especificação e de Arquitetura de Software. A atividade de
Implementação também deve incorporar tarefas de documentação, principal-
mente para descrever e/ou detalhar as instruções que são utilizadas para im-
plementar as funcionalidades do sistema.
7. Suporte e Treinamento de Software – uma grande porcentagem dos pro-
jetos 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. Os
usuários, freqüentemente, terão muitas questões e problemas de software que
permitirão conduzir o desenvolvimento da próxima fase.
8. Manutenção – a manutenção e melhoria de software lidam com a desco-
berta de novos problemas e requisitos. Pode tomar mais tempo que o gasto no
desenvolvimento inicial. Não somente pode ser necessário adicionar códigos
que combinem com o projeto original, mas determinar como o software traba-
lhará 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, mas essas
estatísticas podem estar enganadas, pois uma pequena parte desles 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 conside-
radas um novo trabalho.
A figura 29 ilustra as atividades do processo de desenvolvimento de software e
a interação entre elas.

Figura 29 – Atividades do Processo de Desenvolvimento de Software
1.3 Padrões do Processo
O processo de desenvolvimento de software tem sido objetivo de vários pa-
drões, que visam à certificação das empresas como possuidoras de um processo de
desenvolvimento. Em alguns casos, possuir uma certificação de padrão de processo
de desenvolver pode gerar certo grau de confiança aos contratantes.
Alguns padrões existentes atualmente são:
• CMMI – Capability Maturity Model Integration – é um modelo de referência
que contém práticas necessárias à maturidade em disciplinas específicas como:
Engenharia de Sistemas, Engenharia de Software, Integração de Produtos e
Desenvolvimento de Sof (Systems Engineering (SE), Software Engineering
(SE), Integrated Product and Process Development (IPPD), Supplier Sourcing
(SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade
Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um
modelo único para o processo de melhoria corporativo, integrando diferentes
modelos e disciplinas.
• ISO 12207 – é uma norma definida pela International Organization for Stan-
dardization, que se aplica à Engenharia de Software. Essa norma estabelece
um processo de ciclo de vida do software, contendo processos e atividades
aplicadas durante a aquisição e configuração dos serviços do sistema, de for-
ma a melhorá-los. Seu principal objetivo é fornecer uma estrutura comum para
que os envolvidos com o desenvolvimento de software, utilizem uma lingua-
gem comum.
• SPICE – a ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/

IEC que define um processo de desenvolvimento de software. É uma evolução
da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim
como o CMMI.
• MPS/Br – o MPS.BR ou Melhoria de Processos do Software Brasileiro, é um
modelo de qualidade de processo voltada para a realidade do mercado de pe-
quenas e médias empresas de desenvolvimento de software no Brasil. É ba-
seado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade
do mercado brasileiro.
2 MODELOS DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Há mais de década vem se tentando encontrar um processo ou metodologia
que melhore a produtividade e qualidade dos sistemas de software desenvolvidos.
Algumas propostas tentaram formalizar a tarefa de desenvolver um software. Outras
aplicaram técnicas de gerenciamento de projeto no desenvolvimento de software,
mas como já vimos em aulas anteriores, sem o gerenciamento de projeto, projetos de
software podem facilmente sofrer atraso ou estourar o orçamento.
De acordo com as pesquisas do Standish Group, vimos que o percentual de
projetos bem sucedidos ainda não é suficiente. Isso indica que um grande número de
projetos de software não atende às expectativas em termos de funcionalidades, cus-
to, ou cronograma de entrega, portanto, acredita-se que ainda não existe um modelo
de processo perfeito para todas as aplicações. Na aula 7 verificaremos as principais
tendências para o processo de desenvolvimento de software.
De qualquer forma, devido à grande complexidade do desenvolvimento de sof-
tware, é muito importante que os desenvolvedores e as empresas envoldidas com de-
senvolvimento de projetos de software adotem um modelo de processo para garantir
o sucesso dos seus projetos.
2.2 Modelo Cascata
O modelo cascata é o mais antigo e tem como objetivo desenvolver as ativida-
des do processo de desenvolvimento na ordem seqüencial. A figura 30 ilustra o méto-

do sugerido pelo modelo cascata.
Figura 30 – Modelo Cascata
Os desenvolvedores que utilizam esse modelo estabelecem os requisitos, ana-
lisam os requisitos, projetam uma abordagem para solução, arquitetam um esboço do
software, implementam o código, testam - inicialmente os testes unitários e os testes
de sistema -, implantam e o mantêm. Ao final de cada atividade, o processo segue
para a próxima atividade. Essa característica é considerada uma das desvantagens
do modelo, pois novos requisitos podem surgir na atividade de projeto ou ainda na
atividade de implementação, porém a análise mais detalhada desses itens não é feita
devido à fase de especificação já ter sido desenvolvida.
Assim, se as iterações não são incluídas no planejamento, o processo não tem
meios para corrigir os erros nas etapas inicias, então o processo inteiro da engenharia
de software deve ser executado até o fim, resultando em funcionalidades de software
desnecessárias ou sem uso.
Esse modelo é adequado nas seguintes situações:
• Existe um conjunto de Requisitos estáveis e de alta qualidade – segundo
especialistas, Requisitos sempre sofrem mudanças, sendo esta visão muito
idealista;
• A duração do projeto é pequena, menor que dois anos;
• O sistema completo deve estar disponível de uma única vez.

2.3 Modelo Iterativo e Incremental
O Desenvolvimento iterativo e incremental descreve o desenvolvimento de pe-
quenas partes do software – funcionalidades ou módulos -, porém que sejam abran-
gentes de modo que auxilie os envolvidos a identificar se o desenvolvimento está
sendo feito de acordo com a necessidade e o especificado.
O processo iterativo é preferido por desenvolvedores porque lhes fornece um
potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente
o que quer, ou quando não se conhece bem todos os aspectos da solução.
Os processos de desenvolvimento ágil de software são construídos com os funda-
mentos do desenvolvimento iterativo. Os processos ágeis usam o feedback, mais que
o planejamento, como seus mecanismos de controle primário. O feedback é uma das
práticas que descreve o que foi produzido pelos testes regulares e das versões do
software desenvolvido.
Esse modelo é adequado nas seguintes situações:
• A liberação do software deve estar de acordo com um conjunto de prioridades
definidas nos Requisitos;
• É necessário melhorar a eficiência da integração do software com outra par-
tes de um sistema maior;
• Requerem-se, antecipadamente, evidências de que o produto será aceito.
A figura 31 ilustra o funcionamento do modelo iterativo e incremental.
Figura 31 – Modelo Iterativo e Incremental

2.4 Processo Unificado e RUP - Rational Unified Process
O Processo Unificado é um modelo desenvolvido pelos criadores da linguagem
UML: Ivar Jacobson, James Rumbaugh e Grady Booch. Esse modelo pode ser con-
siderado como o resultado de mais de 30 anos de experiência acumulada dos seus
criadores.
O processo unificado, ou UP, como é conhecido, é o primeiro processo de
desenvolvimento a explorar integralmente as capacidades da linguagem UML. Além
disso, baseia-se nas práticas comuns aos projetos de software indicados como bem
sucedidos.
O processo unificado de software ou RUP – Rational Unified Process – é o
processo de desenvolvimento de software criado com base no processo unificado. A
empresa Rational é a empresa fundada pelos “três amigos”, criadores da UML e do
Processo Unificado. A Rational foi comprada pela IBM no ano de 2003.
A fórmula a seguir, define de maneira resumida o conceito do processo de sof-
tware unificado:
RUP = Processo + Métodos + Linguagem UML
O desenvolvimento de sistemas, seguindo o RUP é um processo:
• Dirigido por casos de uso;
• Centrado na arquitetura;
• Iterativo e incremental.
Veja na figura 32 o processo unificado de software.
Figura 32 – Processo Unificado de Software - RUP

Síntese da Aula
1) O processo de desenvolvimento de software e as suas principais caracterís-
ticas;
2) As atividades do processo de desenvolvimento de software;
3) Os padrões do processo de desenvolvimento de software;
4) Os principais modelos do processo de desenvolvimento de software.
1) Assinale a alternativa incorreta. As características responsáveis pela crise de
software são:
a) Projetos estourando o orçamento;
b) Projetos estourando o prazo;
c) Projetos com planejamento bem definido;
d) Software com baixa qualidade.
2) A atividade do Processo de Desenvolvimento de Software responsável pela
entrevista com usuário e levantamento das informações é:
a) Análise de requisitos de software;
b) Especificação;
c) Manutenção;
d) Suporte e Treinamento de Software.
3) A atividade do Processo de Desenvolvimento de Software que impacta direta-
mente nas demais atividades de software é:
a) Análise de requisitos de software;

b) Especificação;
c) Manutenção;
d) Suporte e Treinamento de Software.
4) O modelo de processo totalmente compatível com a linguagem UML é:
a) Modelo Cascata;
b) Modelo Iterativo;
c) Modelo Incremental;
d) Modelo Unificado.

Aula 6
MODELANDO PROJETOS DE
SOFTWARE
Nesta sexta aula você estudará sobre as principais ati-
vidades desenvolvidas na etapa de análise e projeto de
software. Estudará quais são as atividades dessa etapa, quais as
práticas comuns utilizadas para auxiliar no desenvolvimento das
atividades de modelagem e alguns exemplos de modelagem de
sistemas. Criará alguns diagramas UML com base na ferramenta
JUDE.
Bons Estudos!
Objetivos da Aula
• Enumerar as principais atividades para elaborar
os modelos de software;
• Caracterizar cada atividade da modelagem de software;
• Analisar os exemplos de práticas utilizados para modelar
projetos de software;
• Criar modelos utilizando a lingaugem UML.
Conteúdos da Aula

• Análise e Projeto de Software;

1 ANÁLISE E PROJETO DE SOFTWARE
A modelagem de software se dá principalmente na etapa de análise do projeto
de software, característica em que é aconselhável desenvolver um modelo, analisar
os detalhes de funcionamento por meio do modelo, aperfeiçoá-lo e, por fim, desenvol-
ver o produto final com base no modelo.
A etapa de análise é a etapa na qual se faz o levantamento da necessidade
existente e define-se de que forma o software a ser criado deverá solucionar essa ne-
cessidade. Em alguns ambientes, os desenvolvedores têm o mau costume de “pular”
a etapa de análise indo diretamente para a etapa de desenvolvimento – essa atitude
por ser justificada pela inexperiência dos desenvolvedores ou ainda por falta de um
modelo de processo de desenvolvimento de software definido.
Projetos de software que ocasionalmente não passaram por todas as ativida-
des definidas no processo de desenvolvimento de software, freqüentemente possuem
falhas na definição do software, ou seja, descobre-se, após o desenvolvimento que
o que foi feito não atende à necessidade existente. Dessa forma, é imprescindível
adotar e seguir um modelo para garantir o sucesso no desenvolvimento dos projetos
de software.
As principais atividades desenvolvidas na etapa de análise são:
• Levantamento de informações;
• Análise dos requisitos;
• Transformação dos requisitos em casos de uso e diagramas de casos de
uso;
• Modelagem dos diagramas de classes, seqüência, atividades e estado – a
modelagem de todos os diagramas vai depender da complexidade do projeto
de software;
• Desenvolvimento de protótipos de telas – atividade opcional.

1.2 Levantamento de Informações
Nessa etapa, o analista realiza o levantamento de informações com o usuário.
O analista pode utilizar várias técnicas como entrevistas com o usuário para descobrir
as necessidades existentes. As técnicas mais utilizadas para levantamento de infor-
mações com os usuários são:
• Entrevistas;
• Observação in loco - observação do processo na “casa” do usuário;
• Encontros/Reuniões.
Essas três técnicas são complementares e podem todas ser usadas numa
mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada.
Os analistas entrevistam os usuários para definir os objetivos gerais e as restrições
que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter
o máximo de informações do usuário.
Na observação in loco, os analistas devem estar inseridos na rotina de trabalho
da organização tentando entender e descrever as principais atividades realizadas.
Devem ser identificadas quais são as atividades que podem ser automatizadas; quem
são os potenciais usuários; quais tarefas eles querem realizar com a ajuda do novo
sistema, etc. A observação deve ser complementada com entrevistas específicas com
os futuros usuários.
Os encontros são reuniões envolvendo analistas, clientes e usuários e têm
como objetivo principal o levantamento de informações, a descrição dos problemas
atuais e as metas futuras. É aconselhável que os encontros sejam realizados em um
local neutro - fora da organização e que as informações levantadas, sejam afixadas
em painéis, na sala de encontro para que possam ser analisadas e validadas pelos
clientes e usuários. Ao final do encontro, os analistas devem elaborar um relatório
descrevendo os requisitos analisados.
Independente da técnica de levantamento utilizada, o analista deve estar sem-
pre atento às informações fornecidas pelo usuário, pois cada detalhe mencionado por
usuário, muitas vezes pode resultar em mudanças no planejamento que o analista já
estava realizando.

Nem sempre o usuário tem todas as informações que o analista necessita. Mui-
tas vezes, o usuário tem informação sobre o seu trabalho no momento, mas a diretoria
tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de
conhecimento do usuário. Assim o analista deve sempre consultar outras pessoas
além dos usuários da aplicação.
A tabela 10 mostra um exemplo de questionário que pode ser aplicado em uma entre-
vista com o usuário.
Tabela 10 – Exemplo de Questionário
Qual é o objetivo do Sistema?1.
Que área vai atender?2.
Que tipo e quantos usuários estarão interagindo com o sistema?3.
Quais são as principais funcionalidades que o sistema deverá possuir?4.
Quais funcionalidades os usuários poderão acessar?5.
É necessário utilizar perfil de usuário para definir acesso aos usuários?6.
Qual plataforma o sistema utilizará?7.
Qual o banco de dados que irá utilizar?8.
O sistema estará alocado dentro da empresa ou em um servidor de terceiro?9.
Qual é o prazo de entrega?10.
Necessita de uma equipe para o treinamento do Projeto?11.
Há disponibilidade de alguém para acompanhar o desenvolvimento?12.
Necessita treinamento no processo a ser sistematizado?13.
Necessidade de alguma linguagem específica?14.
Já há informações em arquivos ou banco de outros sistemas?15.
Sistema terá integração com outros sistemas atuais?16.
Há uma limitação de orçamento?17.
Qual é a configuração padrão das máquinas da empresa(Windows 95,98,2000, XP ou Linux)?18.
Haverá manutenção mensal no sistema?19.
O sistema atenderá mais franquias da própria empresa?20.
1.3 Levantamento de Informações
Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do
sistema que definem as diversas propriedades do sistema. Um conjunto de requisitos
pode ser definido como uma condição ou capacidade necessária que o software deve
possuir para:
1. Que o usuário possa resolver um problema ou atingir um objetivo;
2. Ou atender às necessidades e/ou restrições da organização ou dos outros

componentes do sistema.
Tradicionalmente, os requisitos de software são separados em requisitos
funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas
funções que clientes e usuários querem ou precisam que o software ofereça. Definem
a funcionalidade desejada do software. O termo função é usado no sentido genérico
de operação que pode ser realizado pelo sistema, seja através comandos dos usu-
ários ou pela ocorrência de eventos internos ou externos ao sistema. Exemplos de
requisitos funcionais:
1. “O software deve possibilitar o cálculo dos gastos diários, semanais, men-
sais e anuais com pessoal”.
2. “O software deve emitir relatórios de compras a cada quinze dias.”
3. “Os usuários devem poder obter o número de aprovações, reprovações e
trancamentos em todas as disciplinas por um determinado período de tempo.“
A especificação de um requisito funcional deve determinar o que se espera
que o software faça, sem a preocupação de como ele faz. É importante diferenciar a
atividade de especificar requisitos da atividade de especificação que ocorre durante o
desenvolvimento do software. Na especificação do software, deve-se tomar a decisão
de quais funções o sistema efetivamente terá para satisfazer o que os usuários que-
rem / necessitam.
Requisitos não-funcionais são as qualidades globais de um software, como
manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente,
esses requisitos são descritos de maneira informal e são difíceis de validar. Exemplos
de requisitos não-funcionais:
1. “A base de dados deve ser protegida para acesso apenas de usuários auto-
rizados”.
2. “O tempo de resposta do sistema não deve ultrapassar 30 segundos”.
3. “O software deve ser operacionalizado no sistema Linux”.
4. “O tempo de desenvolvimento não deve ultrapassar seis meses”.
A necessidade de se estabelecer os requisitos de forma precisa é crítica à me-

dida que o tamanho e a complexidade do software aumentam. Os requisitos exercem
influência uns sobre os outros. Por exemplo, o requisito de que o software deve ter
grande portabilidade, ser implementado em Java para possibilitar o acesso por celu-
lar, ou dispositivos móveis – pode implicar em que o requisito desempenho não seja
satisfeito.
O resultado final da análise e especificação de requisitos e das outras ativida-
des da fase de definção deve ser apresentado aos clientes para que possam validá-lo.
Esse documento oferece a concordância entre clientes, analistas e desenvolvedores
sobre o que deve ser desenvolvido. É utilizando esse documento que as atividades da
fase de desenvolvimento – codificação – serão validadas.
Cada desenvolvedor utiliza um modelo específico para elaborar este documen-
to. A sua estrutura, muitas vezes, depende do método que está sendo utilizado. Em
linhas gerais, esse modelo deve ser basicamente textual, utilizando o mínimo de ter-
mos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a
visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.
A tabela 11 ilustra uma lista de requisitos funcionais e não-funcionais de um sis-
tema de software. A lista de requisitos se refere às informações levantadas para uma
faculdade que necessita de aplicação para controlar processos acadêmicos como: vi-
sualização de notas pelos alunos, cadastro de disciplinas, alocação de recursos para
as turmas, etc.
Tabela 11 – Lista resumida de requisitos
# Descrição Tipo
1
O sistema deve permitir aos alunos visualizar as notas das
disciplinas por semestre letivo.
Requisito Funcional
2
O sistema deve permitir o lançamento das notas dos alu-
nos por disciplina pelos professores.
Requisito Funcional
3
O sistema deve permitir a abertura de turmas para uma
disciplina, com a definição de sala e laboratórios a serem
utilizados e dos horários e dias da semana em que haverá
aulas.
Requisito Funcional
4 O sistema deve ser desenvolvido para a plataforma WEB Requisito Não-Funcional

1.4 Transformação dos requisitos em casos de uso e diagramas de casos de
uso
Após a definição dos requisitos do sistema de software, é possível dar início
à identificação dos atores e casos de uso para a elaboração do diagrama de casos
de uso. Os atores devem ser encarados como os agentes externos ao sistema, por
exemplo: usuários, outros sistemas, computadores externos, impressoras etc. Já os
casos de uso serão as funcionalidades do sistema ou os requisitos funcionais do sis-
tema.
Para auxiliar na identificação dos atores do sistema, podem ser utilizadas as
seguintes questões:
1. Quem irá utilizar as funções principais do sistema?
2. Quem precisará do sistema para realizar as suas tarefas diárias?
3. Quem irá manter, administrar e deixar o sistema funcionando?
4. Existe interação com outros sistemas? Quais?
5. Quem ou o que está interessado nos resultados (valores) que o sistema
produz?
Com base na lista de requisitos, disponível na tabela 11, e as questões acima
citadas, identificaram-se os seguintes atores:
• Aluno;
• Professor;
• Secretaria.
Para auxiliar na identificação dos casos de uso, podem ser utilizadas as se-
guintes questões:
1. Quais funções os atores necessitam do sistema?
2. O que o ator deve fazer?
3. O ator precisa ler, escrever, apagar, modificar ou armazenar alguma informa-
ção no sistema?
4. O ator precisa ser informado sobre eventos que acontecem no sistema?
5 .O ator precisa notificar o sistema de alguma coisa?

6. O que os eventos 4 e 5 representam em termos de funcionalidade?
7. Os atores podem ter as suas tarefas diárias simplificadas ou feitas de modo
eficiente se alguma nova função for adicionada?
Com base na lista de requisitos, disponível na tabela 11, e as questões acima
citadas, identificaram-se os seguintes casos de uso:
• Visualiza Notas;
• Lança Notas;
• Cadastra Disciplina;
• Abre Turmas;
• Define Horário das Turmas.

Após a identificação dos atores e casos de uso, é possível modelar o diagrama
de casos de uso e, caso seja necessário, detalhar / documentar o caso de uso textual-
mente. O detalhamento do caso de uso é geralmente utilizado quando a funcionalida-
de referente ao caso de uso é um tanto complexa. Caso contrário, um detalhamento
maior não é necessário. O detalhamento do caso de uso pode utilizar o modelo suge-
rido na tabela 5 – aula 4.
Vejam na figura 33 o diagrama de casos de uso modelado de acordo com a
lista de requisitos – tabela 11 – e a identificação dos atores e casos de uso do sistema
de software.

Figura 33 – Diagrama de Casos de Uso
O diagrama ilustrado na figura 33 foi modelado na ferramenta JUDE. Para
elaborar os diagramas UML utilizando o JUDE, basta você seguir as seguintes instru-
ções:
1. Abra a ferramenta por meio do menu: Iniciar >> Programas >> JUDE Com-
munity;
2. Crie um novo arquivo: .jude que possuirá todos os diagramas e modelos
do seu projeto de software clicando em: File >> New ou pelo ícone de atalho:
Create a New File. Dica: para cada projeto de software crie sempre um arquivo
diferente com o nome do projeto. Um arquivo jude poderá possuir vários dia-
gramas – podendo ser várias versões de um mesmo diagrama – dessa forma,
sempre coloque um nome para os diagramas identificando a situação ou fun-
cionalidade que o diagrama representa. Isso facilitará a tarefa de modelagem
de software.
3. Para criar um novo diagrama, basta clicar na opção: Diagram na barra de
ferramentas e selecionar o diagrama desejado. Como a ferramenta está dis-
ponível apenas no idioma inglês, segue abaixo a tradução para os principais
diagramas UML:
a) Diagrama de Caso de Uso = UseCase Diagram

b) Diagrama de Classes = Class Diagram
c) Diagrama de Seqüência = Sequence Diagram
d) Diagrama de Estado = StateChart Diagram
e) Diagrama de Atividade = Activity Diagram
4. Modele o diagrama utilizando os elementos gráficos disponíveis. Se ne-
cessário, volte à aula 4, onde são abordados todos os elementos gráficos dos
diagramas.
1.5 Modelagem dos diagramas de classes, seqüência, atividades e estado
Após a definição do diagrama de casos de uso e a sucessiva validação pelo
cliente - usuário final -, é possível dar continuidade no processo de modelagem do
projeto de software. Não há uma seqüência lógica para a elaboração dos demais
diagramas e também não há uma quantidade específica para cada modelo. A quan-
tidade de diagramas a ser modelado deve estar de acordo com a necessidade de
detalhamento do sistema de software, a fim de abstrair ao máximo a complexidade do
software.
Dos quatro diagramas citados, o diagrama de classes é o mais importante e
mais utlizado nos projetos de softwatre, pois é com base nesse diagrama que as clas-
ses e os objetos do sistema serão criados. Os demais diagramas, como já informado,
poderão ser modelados de acordo com a complexidade do sistema e/ou funcionalida-
des que estão sendo modeladas.
Para auxiliar na identificação das classes do sistema, podem ser utilizadas as
seguintes questões:
1. Existem informações que devem ser registradas ou analisadas?
2. Existe interação com sistemas externos?
3. Existem padrões, bibliotecas, pacotes, componentes, etc a serem utiliza-
dos?
4. Existem informações que devem ser manipuladas de qualquer forma? Quais?
(Detalhar atributos e operações)
5. Existem representações organizacionais?

6. Quais papéis representam os atores no negócio?
7. Existem dispositivos que serão manipulados pelo sistema?
Com base na lista de requisitos da tabela 11 e definição dos casos de uso do
sistema – funcionalidades do sistema (figura 33) – foram identificadas as seguintes
classes para o projeto de software:
• Classes que irão manter os dados dos atores:
• Aluno;
• Professor;
• Secretaria.
• Classes que irão manter os dados das informações do sistema:
• Semestre;
• Disciplina;
• Turma;
• Horário;
• Sala;
• Laboratório;
• Nota.
Veja na figura 34 o diagrama de classes sugerido para o sistema.

Figura 34 – Diagrama de Classes do Sistema
O diagrama de seqüência irá representar o funcionamento interno do sistema,
em relação a uma ou mais funcionalidades. Pode-se utilizar como referência a defini-
ção e o detalhamento dos casos de uso identificados para o sistema. No diagrama de
seqüência será ilustrada a ação de um ator e a troca de mensagens entre os objetos
do sistema, a fim de realizar a operação iniciada pela ação do ator.
Veja na figura 35 o diagrama de seqüência modelado para descrever o funcio-
namento interno do caso de uso: Visualiza Nota.

Figura 35 – Diagrama de Seqüência do Caso de Uso: Visualiza Nota
O diagrama de estado irá ilustrar o funcionamento interno de um objeto do
sistema. Nesse diagrama serão ilustrados os estados que um objeto poderá assumir,
dependendo da operação realizada pelo ator ou pelo próprio objeto. Esse diagrama
deve ser utilizado somente para os objetos que possuem uma complexidade conside-
rável e necessitam de detalhamento para melhor análise.
A figura 36 ilustra o diagrama de estado modelado para descrever o funciona-
mento interno do objeto: Turma.
Figura 36 – Diagrama de Estado do Objeto: Turma
O diagrama de atividades irá ilustrar o fluxo de dados de uma ou mais funcio-

nalidades, além da interação dessa funcionalidade com os atores do sistema. Esse
diagrama também poderá ser modelado com base na definição e detalhamento dos
casos de uso identificados no sistema.
Veja na figura 37 o diagrama de atividades modelado para descrever o fluxo de
dados do caso de uso: Visualiza Nota.
Figura 37 – Diagrama de Atividade do Caso de Uso: Visualiza Nota
1.6 Desenvolvimento de protótipos de telas
Essa atividade é uma tarefa opcional, pois sua finalidade é demonstrar de for-
ma visível o layout das telas do sistema a ser desenvolvido. É muito útil para sistemas
extremamente complexos e com grande quantidade de telas, porém, mesmo nesse
caso, é aconselhável desenvolver os protótipos das telas mais complexas, para evitar

desperdício de tempo em atividades que não irão agregar qualidade ou produtividade
ao produto final.
Ferramentas CASE como o VISIO da Microsoft permitem o desenvolvimento de
protótipos com grande qualidade e proximidade do layout das telas do sistema real.
Veja na figura 38 um exemplo de protótipo de tela desenvolvido com o VISIO.
Figura 38 – Protótipo de Tela
Síntese da Aula
1) As principais atividades desenvolvidas na etapa de análise e projeto de sof-
tware;
2) As melhores práticas para o desenvolvimento das atividades;
3) Como modelar os principais diagramas UML;
4) Exemplos de métodos e técnicas que podem ser aplicadas durante a mode-
lagem de projetos de software.

1) Analise os requisitos abaixo e desenvolva as seguintes atividades:
a) Identificação dos Atores do Sistema;
b) Identificação dos Casos de Uso do Sistema;
c) Elaboração do Diagrama de Casos de Uso;
d) Identificação das Classes do Sistema;
e) Elaboração do Diagrama de Classes.
# Descrição Tipo
1
O sistema deve permitir ao Funcionário ca-
dastrar Clientes contendo os dados: nome,
endereço, e telefone
Requisito Funcional
2
dastrar Cidades que representam os lugares
abrangidos pela empresa de transportes e
contêm o nome da cidade, o estado a que
pertence e o valor para a taxa de entrega
Requisito Funcional
3
dastrar Fretes contendo um código, uma des-
crição, o peso total, um cliente e a cidade de
destino, não podendo haver um frete sem os
dados citados. Cada frete deve ter ainda o
seu valor, que deve ser calculado por meio do
peso multiplicado por um valor fixo, acrescido
da taxa de entrega da cidade de destino
Requisito Funcional
4 O sistema deve ser para plataforma WEB Requisito Não-Funcional

Aula 7
TENDÊNCIAS DO PROCESSO DE
ENGENHARIA DE SOFTWARE
Nesta aula você estudará sobre as principais tendências
para o desenvolvimento e gerenciamento de sistemas de
software. Verificará os principais temas discutidos pela comunida-
de de engenharia de software.
Bons Estudos!
Objetivos da Aula
• Identificar as principais tendências para o desenvolvimento
e gerenciamento de projetos de software.
Conteúdos da Aula

• A importância do Software;
• Metodologias Ágeis;

1 A IMPORTÂNCIA DO SOFTWARE
O software de computador é uma dentre poucas tecnologias-chave que causa-
ram impacto sobre quase todos os aspectos da sociedade moderna durante a década
de 1990. É um mecanismo para automatizar os negócios, a indústria e o governo, um
meio de transferir novas tecnologias, um modo de captar valiosa experiência para ser
usada por outros, um meio de diferenciar os produtos de uma empresa dos de seus
concorrentes e uma janela para o conhecimento corporativo coletivo (PRESSMAN,
1995, p. 1010).
É realmente impressionante a capacidade com que o software teve de se in-
filtrar em todas as áreas de atuação da sociedade. Atualmente, é muito difícil irmos
a um lugar ou qualquer estabelecimento que não possua um software ou sistema de
informação que permita gerenciar, automatizar ou suportar algumas das atividades.
É possível também, verificar a evolução dos softwares que vêm sendo desen-
volvidos atualmente. A disseminação e busca pela melhoria no desenvolvimento de
software também aumentou após a popularização dos meios de comunicação e servi-
ços oferecidos por meio da Internet. É muito comum, nos dias atuais, que as pessoas
realizem compras, como a compra de um livro, por exemplo, em uma loja virtual dispo-
nível na Internet. Também é bastante comum que empresas de segmentos diversos
tenham o seu cartão de visitas disponível em forma de um site na Internet.
E a evolução não pára por aí. O software tem atingido ambientes diversos
também, fora do mundo dos computadores e sua rede mundial. Tendências como:
softwares embarcados – sistema específico que faz parte de um minicomputador,
máquina ou sistema mais amplo -, tecnologias móveis – sistema desenvolvido para
aparelhos de celulares e outros dispositivos móveis – e sistemas para televisão digital
têm proporcionado uma grande evolução na área da engenharia de software, que vem
expandindo com grande velocidade a sua área de atuação.
Conforme a área de atuação da engenharia de software foi aumentando, mu-
danças no processo de desenvolvimento e nas técnicas utilizadas começaram a sur-
gir. O objetivo dessas mudanças é sempre a melhoria no processo de desenvolvi-
mento de projetos de software a fim de produzir softwares com maior produtividade e

qualidade.
Segundo PRESSMAN (2002, p. 1013), as mudanças que afetarão a engenha-
ria de software ao longo das próximas décadas serão influenciadas a partir de quatro
direções simultâneas: (1) as pessoas que fazem o trabalho; (2) o processo que elas
aplicam; (3) a natureza da informação; (4) e a tecnologia de computação subjcente.
1.2 Software baseada em Componentes
Engenharia de Software Baseada em componentes é um ramo de Engenharia
de Software, com ênfase na decomposição dos sistemas em componentes funcionais
e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios
componentes.
Componentes estão em um nível de abstração mais alto que do que Objetos,
porém comunicam-se por troca de mensagens contendo dados. Os componentes
possuem uma interface e também empregam regras de herança. São definidos para
oferecer certo nível de serviço. No caso dos componentes “comerciais de prateleira”,
o engenheiro de software sabe pouco ou nada sobre o seu funcionamento interno.
Ao invés disso, ao engenheiro de software é dada apenas uma interface externa bem
definida a partir da qual ele deve trabalhar.
Ao contrário de objetos em OO, os componentes são usualmente construídos a
partir de muitos “objetos” de software e fornecem uma unidade de funcionalidade co-
erente. Os assim chamados “objetos” trabalham em conjunto para realizar uma tarefa
específica em um dado nível de serviço.
A grande vantagem de se trabalhar com componentes é a possibilidade de
reutilização, por meio da qual tanto a produtividade quanto a qualidade seriam bene-
ficiadas, pois um componente deve possuir exatidão na função que desempenha.
1.3 Padrões de Projetos
Os padrões de projeto, também muito conhecido pelo termo original em inglês:
Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimen-
to de sistemas de software orientados a objetos. Um padrão de projeto estabelece um

nome e define o problema, a solução, quando aplicar essa solução e suas conseqü-
ências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho -
isto é, soluções na fase de projeto do software, sem considerar reutilização de código.
Também acarretam um vocabulário comum de desenho, facilitando comunicação, do-
cumentação e aprendizado dos sistemas de software.
O movimento ao redor de padrões de projeto ganhou popularidade com o li-
vro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em
1995. Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John
Vlissides, conhecidos como a “Gangue dos Quatro” (Gang of Four) ou simplesmente
“GoF”. Posteriormente, vários outros livros do estilo foram publicados, como Applying
UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Itera-
tive Development, que introduziu um conjunto de padrões conhecidos como GRASP
(General Responsibility Assignment Software Patterns).
2 METODOLOGIAS ÁGEIS
Um desafio constante da área de Engenharia de Software é a melhoria no
processo de desenvolvimento de software. Mesmo com a evolução de métodos, téc-
nicas e ferramentas, nem sempre se consegue entregar software em prazos e custos
estabelecidos nem sempre é conseguida. Vimos na figura 1 (aula 1), de acordo com
as pesquisas realizadas pelo órgão Standish Group, que apenas 34% dos projetos de
software são bem-sucedidos.
De acordo com os pesquisadores da área de metodologias ágeis, uma das
causas desse problema pode ser o excesso de formalidade nos modelos de processo
propostos nos últimos 30 anos. Documentações extensivas e artefatos que muitas ve-
zes são desenvolvidos no início do projeto e depois “engavetados” durante o processo
de desenvolvimento, são apontadas como as principais causas de não sucesso dos
projetos.
Com o avanço sucessivo da tecnologia e o aumento da velocidade de sua
propagação, surge cada vez mais a necessidade de desenvolver software de forma
mais rápida, porém sempre privando pela qualidade. Esse aumento na capacidade

da produtividade de desenvolvimento dos softwares pode ser conseguido por meio da
aplicação de métodos ágeis e padrões organizacionais de processo.
Há alguns anos, um grupo de veteranos na área de software se reuniu, nos
EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada
envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de
software ter sucesso, todos concordavam que, em suas experiências prévias, um pe-
queno conjunto de princípios sempre era respeitado quando os projetos davam certo.
Com base nisso, criaram o Manifesto para o Desenvolvimento Ágil de Software
– em 17 de fevereiro de 2001 -, freqüentemente chamado apenas de Manifesto Ágil.
Os princípios propostos pelo Manifesto Ágil segundo Beck ( 2001), são:
“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós
mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valori-
zar:
• Indivíduos e interações são mais importantes que processos e ferramen-
tas;
• Software funcionando é mais importante do que documentação detalhada;
• Colaboração dos clientes é mais importante do que negociação de contra-
tos;
• Adaptação às mudanças é mais importante do que seguir um plano.
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à es-
querda.”
O “Manifesto Ágil” não rejeita os processos e ferramentas, a documentação,
a negociação de contratos ou o planejamento, mas simplesmente mostra que eles
têm importância secundária quando comparado com os indivíduos e interações, com
o software estar executável, com a colaboração do cliente e as respostas rápidas a
mudanças e alterações. Esses conceitos aproximam-se melhor com a forma que pe-
quenas e médias organizações trabalham e respondem a mudanças.
Assim, foi a partir do “Manifesto Ágil” que ocorreu a popularização dos métodos
ágeis que passaram a ser usados em empresas, universidades, institutos de pesqui-
sa e até em agências governamentais. Algumas das metodologias ágeis existentes

são:
• XP (eXtreme Programming);
• DSDM (Dynamic Systems Development Method);
• Família Crystal;
• ASD (Adaptive Software Development);
• SCRUM;
• FDD (Feature-driven development);
• LD (Lean Development);
• Open Source.
Com exceção dos autores das metodologias: LD e OpenSource, os demais
autores das metodologias citadas participaram da criação do Manifesto Ágil, portanto,
possuem princípios em comum.
Síntese

1) A importância do software;
2) Conceitos básicos sobre Engenharia de Software Baseada em Componen-
tes;
3) Conceitos básicos sobre Padrões de Projeto;
4) Conceitos básicos sobre Metodologias Ágeis.

Exercícios propostos
1) Assinale a alternativa incorreta. De acordo com PRESSMAN, as mudanças
que podem afetar a Engenharia de Software são:
a) Pessoas que desenvolvem;
b) Processo de desenvolvimento;
c) Natureza da Informação;
d) Certificação de Padrão.
2) Os componentes:
a) Possuem várias funcionalidades;
b) Possuem uma interface bem definida;
c) Implementam Herança;
d) Comunicam-se por meio de troca de mensagens de dados.
3) Assinale a alternativa incorreta. É objetivo das Metodologias Ágeis:
a) Entregar software funcionando;
b) Aumentar o nível de documentações;
c) Incluir o cliente em todo o processo de desenvolvimento;
d) Adaptação às mudanças.

Aula 8
ESTUDO DE CASO: MODELANDO
UM PROJETO DE SOFTWARE
Caros alunos, chegamos à última aula da disciplina. Nesta
aula aplicaremos os conceitos de modelagem vistos até
agora, a fim de consolidar o conhecimento no processo de modela-
gem de produtos de software.
Bons Estudos!
Objetivos da Aula
• Desenvolver as principais atividades de modelagem de
software;
• Elaborar os diagramas UML com a ferramenta JUDE.
Conteúdos da Aula

• Definição do Estudo de Caso e elaboração dos modelos
de software.

1 DEFINIÇÃO DO ESTUDO DE CASO
Nesta aula, apresentaremos uma descrição inicial do estudo de caso que guia-
rá as atividades do processo de desenvolvimento de software e a modelagem de sis-
temas de software.
O estudo de caso refere-se a um software que possibilite a gestão de festas
de casamento. O software deverá permitir ao usuário, dentre outras coisas, escolher
o buffet, se haverá grupo musical, escolher tipo de decoração, entre outros itens. O
usuário também poderá definir uma loja para disponibilização da lista de presentes. O
sistema deverá emitir relatório das vendas realizadas por período e gerar orçamento.
Com base na definição do estudo de caso, vamos iniciar a atividade de análise e
projeto de software e, por conseguinte a tarefa de identificação dos requisitos do sof-
tware.
1.2 Identificação dos Requisitos
Para auxiliar na tarefa de identificação dos requisitos de software, vamos revi-
sar as possíveis definições para requisitos:
• Característica do sistema ou a descrição de algo que o sistema seja capaz de
realizar para atingir seus objetos;
• As descrições de funções e restrições do sistema;
• Propriedade que o software deve exibir para resolver algum problema no
mundo real;
• Condição ou capacidade que deve ser alcançada ou estar presente em um
sistema para satisfazer um contrato, padrão, especificação ou outro documen-
to formalmente imposto.
Enfim, podemos traduzir a definição de requisitos como um conjunto de ne-
cessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um
determinado problema de negócio do qual o cliente faz parte.
Os requisitos são classificados em dois tipos:

• Funcionais – diretamente ligados à funcionalidade do software, descrevem
as funções que o software deve executar;
• Não-Funcionais – expressam condições que o software deve atender ou
qualidades específicas que o software deve ter.
Os requisitos identificados para o software do estudo de caso proposto, podem
ser visualizados na tabela 12.
Tabela 12 – Requisitos do sistema do estudo de caso
# Descrição Tipo
1
O sistema deve permitir que o gerente cadastre salões
de festas
Requisito Funcional
2
O sistema deve permitir que o gerente cadastre pro-
fissionais
Requisito Funcional
3
O sistema deve permitir que o gerente realize o cadas-
tro de serviços utilizados em uma festa de casamento,
como buffet e carros utilizados
Requisito Funcional
4
O sistema deverá permitir que o cliente realize o ca-
dastro da lista de convidados
Requisito Funcional
5
O sistema deverá permitir que o cliente elabore a con-
figuração da festa
Requisito Funcional
6
O sistema deverá permitir a geração do orçamento
para o cliente
Requisito Funcional
7
O sistema deverá permitir que o gerente realize a im-
pressão de relatório de festas
Requisito Funcional
8
O sistema deverá permitir que o cliente cadastre a lista
de presentes
Requisito Funcional
9
O sistema deverá permitir que o gerente realize o ca-
dastro de usuários
Requisito Funcional
10
O sistema deverá permitir a autenticação dos usuá-
rios
Requisito Funcional
11
O sistema deve ser compatível com os navegadores
Internet Explorer e Firefox
Requisito Não-Funcional
12
O sistema deve garantir que o tempo de retorno das consul-
tas seja inferior a 5 segundos
Requisito Não-Funcional

1.2 Identificação dos Atores e Casos de Uso
Após a identificação dos requisitos de software e sua classificação em fun-
cionais e não-funcionais, podemos dar início às tarefas de identificação dos atores e
casos de uso do sistema.
Apenas para relembrarmos, os atores são os agentes externos ao sistema,
porém possuem acesso às funcionalidades disponíveis no sistema. Essas funcionali-
dades são os próprios casos de uso.
Com base na definição inicial do sistema proposto pelo estudo de caso e a
identificação e definição dos requisitos de software, encontramos os seguintes atores
e casos de uso:
• Atores: Gerente, Cliente;
• Casos de Uso:
• Cadastra Salão de Festa;
• Cadastra Serviço;
• Cadastra Profissional;
• Configura Festa;
• Gera Relatório;
• Cadastra Usuário;
• Autentica Usuário.
Vimos que, dependendo da complexidade da funcionalidade – caso de uso – é
possível também nesta fase elaborar o detalhamento do caso de uso de modo textual.
No sistema de festas de casamento, proposto pelo estudo de caso, elaboraremos o
detalhamento do caso de uso: Autentica Usuário. Esse detalhamento permite uma
análise mais criteriosa a respeito do funcionamento do caso de uso e suas principais
características.
Veja na tabela 13 o detalhamento elaborado para o caso de uso: Autentica Usu-
ário.

Tabela 13 – Especificação do Caso de Uso: Autentica Usuário
Caso de Uso: Autentica Usuário
Sumário:
Efetuar o login dos usuários no sistema de acordo com o perfil de cada
um e exibir as telas permitidas para cada perfil.
Ator Primário: Gerente
Ator Secundário: Cliente
Pré-Condição: Usuário acessa o sistema
Fluxo Principal:
1. O sistema apresenta formulário contendo as informações: Login e
Senha, além das opções: Entrar e Cancelar.
2. Usuário informe os dados e seleciona a opção: Entrar [A1].
3. O sistema verifica a autenticidade dos dados informados pelo usuá-
rio [A2].
4. O sistema autentica o usuário e apresenta a tela com as opções que
ele pode acessar.
5. Caso de uso é encerrado.
Fluxo Alternativo:
A1. Usuário seleciona a opção: Cancelar
a. Caso de Uso é encerrado
A2. Login ou senha inválida
a. O sistema apresenta a mensagem: “Usuário ou senha inválido”
e a opção: OK.
b. O usuário seleciona a opção OK.
c. O caso de uso retorna para o passo 2 do fluxo principal.
1.4 Elaborando Diagrama de Casos de Uso
Após a identificação dos atores e os casos de uso, é possível elaborar o dia-
grama de casos de uso que irá ilustrar a relação dos atores com as funcionalidades
do sistema – casos de uso do sistema. A figura 39 ilustra o modelo de diagrama de
casos de uso proposto para o estudo de caso.
Figura 39 – Diagrama de Casos de Uso do Estudo de Caso

1.5 Identificando as Classes do Estudo de Caso
A partir da identificação dos atores e casos de uso e da elaboração do diagra-
ma de casos de uso, é possível iniciar a tarefa de identificação das classes do sistema
do estudo de caso proposto.
Para identificar as classes, deve-se utilizar o conhecimento sobre o domínio do
problema – negócio que está sendo modelado – e a especificação de requisistos de
software elaborada. Deve-se procurar na especificação de requisitos, conceitos que
representem objetos do mundo real e que necessitam ser manipulados e/ou armaze-
nados pelo sistema.
Para o estudo de caso, foram identificadas as seguintes classes:
• Salão;
• Profissional;
• Serviço;
• Festa;
• Loja;
• Presente;
• Lista de Presente;
• Lista de Convidado;
• Convidado;
• Usuário.
1.6 Elaborando o Diagrama de Classes
Após a identificação das classes do sistema, podemos iniciar a elaboração do
diagrama de classes. Nessa etapa, devem ser realizadas as seguintes tarefas:
1. Identificação dos atributos das classes – atributos são as propriedades que
caracterizam o objeto;
2. Identificação das operações das classes – operações definem as ações que
um objeto pode realizar;
3. Identificação dos relacionamentos entre as classes;
4. Revisão do modelo elaborado.

Para o estudo de caso proposto, com base nas atividades de modelagem já
realizadas, foi elaborado o diagrama de classes ilustrado na figura 40.
Figura 40 – Diagrama de Classes do Estudo de Caso
1.7 Elaborando os Diagramas de Seqüência, Estados e Atividades
Como vimos na aula 6 – Modelando Projetos de Software – a elaboração dos
diagramas de seqüência, estados e atividades devem ser realizadas de acordo com
a complexidade do sistema de software a ser desenvolvido. No estudo de caso pro-
posto, elaboraremos apenas o diagrama de seqüência de uma das funcionalidades
do sistema. Os demais diagramas ficam como sugestão de lição de casa para você
treinar as habilidades e conhecimentos adquiridos na disciplina.
O diagrama de seqüência que elaboraremos, representa o funcionamento in-

terno do caso de uso: Autentica Usuário. A elaboração do diagrama de seqüência será
sempre feito com base na especificação dos requisitos de software, definição do caso
de uso e modelo de classes elaborado – diagrama de classes.
A figura 41 ilustra o diagrama de seqüência proposto.
Figura 41 – Diagrama de Seqüência do Estudo de Caso Proposto

CONCLUSÃO
Possuir um software que auxilie em tarefas diversas tornou-se algo muito co-
mum nos dias de hoje. Porém, mesmo com a grande evolução que o software vem
sofrendo nas últimas décadas e da quantidade e diversidade de tecnologias que sur-
giram; desenvolver software ainda é considerado uma atividade complexa.
A questão central: complexidade gira em torno, principalmente, das etapas ini-
ciais do projeto de software, consideradas como primordiais para o sucesso do produ-
to resultante do processo. Nessas etapas, é realizada a compreensão do problema
de negócio a ser solucionado pelo software, portanto, são etapas que requerem um
alto grau de experiência – por parte dos desenvolvedores – e grande atenção, a fim
de identificar todos os requisitos e as possíveis variações decorrentes do processo de
desenvolvimento de software.
Portanto, é imprescindível aos profissionais de informática, em especial àque-
les que desejam trabalhar com desenvolvimento de software, possuir o conhecimento
dos principais assuntos relacionados ao tema e também das práticas utilizadas no
processo de desenvolvimento de software. Esse conhecimento irá possibilitar ao pro-
fissional diversas oportunidades e habilidades para o desenvolvimento de projetos de
sucesso.
Assim, esse módulo teve como objetivo principal fazer uma introdução aos co-
nhecimentos básicos sobre os principais elementos dos projetos de software e às
melhores práticas para o processo de desenvolvimento.

REFERÊNCIAS
BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponível em:
http://www.agilemanifesto.org.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de
Janeiro: Elsevier, 2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio
de Janeiro: Elsevier, 2005.
Dicionário Aurélio Online. Disponível em: http://200.225.157.123/dicaureliopos/
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Makron Books,
1995.
WIKIPÉDIA, a enciclopédia livre. Artigos Eletrônicos. Disponível em: http://
pt.wikipedia.org/

APÊNDICE 1
1 O PARADIGMA DA ORIENTAÇÃO A OBJETOS
Um paradigma é a forma de abordar um problema. Alan Kay, um dos pais do
paradigma da orientação a objetos, imaginou o funcionamento do sistema de software
como o de um ser vivo. Nesse sistema, cada “célula” interagiria com outras células
por meio de mensagens para realizar um objetivo comum.
Alan Kay pensou em construir um sistema de software a partir de agentes autô-
nomos (atuais objetos) que interagem entre si. Assim, foram estabelecidos os seguin-
tes princípios da orientação a objetos:
Qualquer coisa é um objeto;
Objetos realizam tarefas por meio da requisição de serviços a outros objetos;
Cada objeto pertence a uma determinada classe;
Uma classe agrupa objetos similares;
A classe é um repositório para comportamento associado ao objeto;
Classes são organizadas em hierarquias.
Exemplo da utilização dos princípios da OO:
Para comprar uma pizza1. VOCÊ que está muito ocupado, pede sua pizza por tele-
fone;
VOCÊ2. informa ao ATENDENTE seus dados e as características da pizza que de-
seja comprar;
O3. ATENDENTE atende sua solicitação e comunica ao PIZZAIOLO seu pedido;
O4. PIZZAIOLO faz a pizza e chama o ENTREGADOR;
O5. ENTREGADOR pega a pizza e a entrega para VOCÊ na sua casa.
Nesse caso, todos os objetos: VOCÊ, ATENDENTE, PIZZAIOLO e ENTREGA-
DOR trabalharam juntos para alcançar o objetivo comum: entregar a pizza quentinha
na sua casa!
O paradigma da OO visualiza um sistema de software como uma coleção de
agentes interconectados (objetos). Cada objeto é responsável por realizar tarefas

específicas e é por meio da interação entre os objetos que uma tarefa computacional
é realizada.
Utilizar a OO para modelagem de sistemas diminui a diferença semântica entre
a realidade sendo modelada e os modelos construídos. A figura 42 ilustra a interação
entre os objetos.
Figura 42 – Interação entre os objetos
1.1 O princípio da abstração
Uma abstração é qualquer modelo que inclui os aspectos mais importantes e
essenciais de alguma coisa. As abstrações permitem gerenciar a complexidade e
concentrar a atenção nas características essenciais de um objeto.
Uma abstração é dependente da perspectiva: o que é importante em um con-
texto pode não ser importante em outro.
As principais características da abstração são:
Permite concentrar nos aspectos essenciais de uma aplicação;
Foca no que um objeto faz, antes de definir como implementá-lo.
Veja na figura 43 os conceitos que envolvem a abstração da OO.

Figura 43 – Princípios da OO
1.1.1 Encapsulamento
As principais características do encapsulamento são:
Forma de restringir o acesso ao comportamento interno de um objeto;
Ocultamento de informações;
Separa os aspectos externos de um objeto, que são acessíveis a outros ob-
jetos, dos detalhes internos da implementação, escondidos de outros objetos.
1.1.2 Polimorfismo
O polimorfismo é a capacidade de abstrair várias implementações diferentes
em uma única interface. Exemplo: o controle remoto da televisão também funciona
com o aparelho de DVD.
O polimorfismo garante que objetos semelhantes possuam interfaces diferen-
tes.
1.1.3 Herança
As principais características da Herança são:
Classes semelhantes são agrupadas em hierarquias;
Cada nível da hierarquia pode ser visto como um nível de abstração;
Cada classe em um nível da hierarquia herda as características das classes nos
níveis acima.
A figura 44 ilustra um exemplo de herança.

Figura 44 – Exemplo de Herança
1.1.5 Objetos
Os objetos estão em toda parte no mundo real:
Pessoas, Animais, Plantas, Carros, Aviões, Edifícios, Computadores, etc;
Todos os objetos têm atributos, por exemplo: tamanho, forma, cor e peso. E
todos exibem comportamento, por exemplo: uma bola rola, rebate, infla e murcha.
Diferentes objetos podem ter atributos semelhantes e podem exibir compor-
tamentos semelhantes. É possível fazer comparações, por exemplo, entre bebês e
adultos, e entre humanos e animais.
As principais características dos objetos são:
Objeto é uma entidade, uma coisa que possui um estado e um comportamento;
O estado de um objeto é caracterizado pelas suas variáveis (atributos);
O comportamento, pelas suas funções (métodos);
Cada objeto é único em seu escopo.
1.1.6 Estado dos Objetos
O estado de um objeto é definido pelas suas características internas, como
peso, altura e profissão para uma pessoa. Em uma linguagem de programação, es-
sas características são implementadas através de variáveis.

Na nomenclatura de OO, as variáveis de um objeto são chamadas de atribu-
tos.
1.1.7 Comportamento dos Objetos
O comportamento é definido pelas tarefas que um objeto é capaz de realizar,
como ler e escrever no caso de uma pessoa. As tarefas são implementadas através
de funções. As funções são chamadas de métodos em OO.
1.1.8 Objetos e Classes
Objetos afins são reunidos em categorias que descrevem suas características
comuns. Em OO, essas categorias são chamadas de classes. As classes são apenas
descrições de estados e comportamentos (abstração) e o objeto é criado por meio de
uma classe.
Exemplo: Planta da Casa é uma classe, a casa construída é o objeto.

Copyright © Tupy Virtual 2007
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
Autores: Rosemary Francisco
Elementos de Projetos de Informática: Material didático / Rosemary Francisco
Design institucional: Thiago Vedoi de Lima; Cristiane de Oliveira - Joinville: Tupy Virtual, 2007
Ficha catalográfica elaborada pela Biblioteca Universitária Tupy Virtual
Créditos
SOCIESC – Sociedade Educacional de Santa Catarina
Tupy Virtual – Ensino a Distância
Rua Albano Schmidt, 3333 – Joinville – SC – 89206-001
Fone: (47)3461-0166
E-mail: ead@sociesc.org.br
Site: www.sociesc.org.br/portalead
Diretor Geral
Sandro Murilo Santos
Diretor de Administração
Vicente Otávio Martins de Resende
Diretor de Ensino, Pesquisa e Extensão
Roque Antonio Mattei
Diretor do Instituto Superior Tupy
Wesley Masterson Belo de Abreu
Diretor da Escola Técnica Tupy
Luiz Fernando Bublitz
Coordenador da Escola Técnica Tupy
Alexssandro Fossile
Alan Marcos Blenke
Coordenador do Curso
Juliano Prim
Coordenador de Projetos
José Luiz Schmitt
Revisora Pedagógica
Nádia Fátima de Oliveira
EQUIPE TUPY VIRTUAL
Raimundo Nonato Gonçalves Robert
Wilson José Mafra
Thiago Vedoi de Lima
Cristiane Oliveira
Janae Gonçalves Martins
Design Gráfico
Professor Responsável
Rosemary Francisco
EDIÇÃO – MATERIAL DIDÁTICO
Professor Conteudista
Rosemary Francisco
Design Institucional
Cristiane Oliveira
Ilustração Capa
Projeto Gráfico
Equipe Tupy Virtual
Revisão Ortográfica
Nádia Fátima de Oliveira

Apostila elementos de projeto de informática

Mais conteúdo relacionado

Mais procurados

Semelhante a Apostila elementos de projeto de informática

Apostila elementos de projeto de informática