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

Apostila elementos de projeto de informática

Apostila elementos de projeto de informática

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Apostila elementos de projeto de informática

Ähnlich wie Apostila elementos de projeto de informática (20)

Apostila elementos de projeto de informática