Apostila Elementos de Projeto de Informática PDF

ELEMENTOS DE PROJETOS DE INFORMTICA
Edio n 1 - 2008
ROSEMARY FRANCISCO
Apoio Gesto e Execuo Contedo e Tecnologia

2 Elementos de Projetos de Informtica
Apresentao
Este livro didtico contm a disciplina de Elementos de Projetos de Inform-

tica.
O contedo deste livro ir disponibilizar aos alunos do EAD os conceitos funda-
mentais sobre o processo de desenvolvimento de projetos de informtica. Por meio
deste material, ser possvel conhecer as fases do processo de desenvolvimento de
software e as melhores prticas que possibilitam: identificar e analisar um problema,
modelar a soluo deste problema e, tambm, como gerenciar todas as fases deste
processo durante a evoluo de um projeto.
Para sua melhor compreenso, o livro est estruturado em quatro partes: na
primeira, apresentaremos os conceitos bsicos sobre projetos de informtica e os
dois principais elementos que sero utilizados durante o processo de desenvolvimen-
to de software; na segunda, as principais caractersticas 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 tcnicas utilizadas para iniciar um projeto e fazer
o correto acompanhamento durante a evoluo das fases de desenvolvimento; na
quarta e ltima parte do livro, desenvolveremos um estudo de caso que permitir a
consolidao dos conhecimentos adquiridos nesta disciplina.
Lembre-se de que a sua passagem por esta disciplina ser acompanhada tam-
bm 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 dvida 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
SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica 3
SUMRIO
CARTA DA PROFESSORA......................................................................................... 4
CRONOGRAMA DE ESTUDOS.................................................................................. 6
PLANO DE ESTUDOS................................................................................................. 7
Aula 1 Introduo a Projetos de Informtica........................................................ 8
Aula 2 Introduo a UML...................................................................................... 20
Aula 3 Introduo 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 Tendncias do Processo de Engenharia de Software........................... 96
Aula 8 Estudo de Caso: Modelando um Projeto de Software......................... 103
Referncias..............................................................................................................112
Apndice 1 Reviso Paragima Orientao a Objetos.......................................113

Carta da Professora
Caro(a) aluno(a),
Nos prximos captulos, ter incio a caminhada rumo ao conhecimento dos

principais elementos para o desenvolvimento de projetos de informtica, 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, necessrio que os profissionais envolvidos conheam grande parte
das informaes relacionadas ao projeto e, principalmente, compreendam qual o
problema que deve ser resolvido. Porm, como um software um objeto abstrato, o
resultado final no palpvel como uma casa ou um edifcio, seu processo de desen-
volvimento considerado complexo.
O processo de desenvolvimento de software tem sido aprimorado desde o in-
cio da dcada de 1980 e, ainda hoje, h vrias discusses e constantes grupos de
pesquisa para aperfeioamento de tcnicas que possam contribuir com melhorias
para esse processo.
Com a evoluo do paradigma da Orientao a Objetos, o processo de desen-
volvimento de software comeou a se beneficiar de novas tcnicas de modelagem de
software - como a linguagem UML - que surgiram para auxlio no desenvolvimento
e tambm para a minimizao da complexidade que envolve o desenvolvimento de
sistemas de softwares. Essas tcnicas vm sendo utilizadas com bastante nfase,
principalmente nas empresas denominadas: Fbricas de Software empresas cujo
negcio o desenvolvimento de projetos de software diversos para outras empresas,
independente do tipo de software.
Porm, no so somente as Fbricas de Software que utilizam as tcnicas de
modelagem e desenvolvimento de software, todas as empresas que possuem em
sua estrutura uma rea de desenvolvimento de projetos de software, tambm esto
fazendo uso dessas tcnicas para garantir o sucesso da soluo empregada para a
resoluo dos problemas identificados.

Portanto, muito importante que o profissional de informtica conhea as

tcnicas 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 estaro inseridos em projetos de software e
tambm quais as melhores prticas para o desenvolvimento desses projetos.
Durante esta caminhada, conheceremos: a origem dos projetos de software, o
que e quais os benefcios de utilizar a UML em projetos de software, conhecer o que
so 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-
rsticas 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 contedos das aulas, e atualize as pos-

sveis datas de realizao de aprendizagem e avaliaes.
Semana Carga horria Aula Data/ Avaliao

Introduo a Projetos de
4
Informtica _/_ a _/_
1 4 Introduo a UML
_/_ a _/_
Introduo a Ferramentas
8
CASE _/_ a _/_
Conhecendo os principais
8
diagramas da UML _/_ a _/_
2
Conhecendo o Processo de
8
desenvolvimento de Software _/_ a _/_
Modelando Projetos de
12
Software _/_ a _/_
3
Tendncias do Processo de
4
Engenharia de Software _/_ a _/_
Estudo de Caso: Modelando um
4 12
Projeto de Software _/_ a _/_

Plano de Estudos
Ementa
Introduo a projetos de desenvolvimento de software; Viso geral da linguagem

UML; Principais Diagramas da Linguagem UML; Introduo a ferramentas CASE; In-
troduo ao Processo de Desenvolvimento de Software; Principais Caractersticas do
Processo de desenvolvimento de Software; Introduo s melhores prticas de mo-
delagem e desenvolvimento do software; Projetar, gerenciar e implementar sistemas
de Software.
Objetivos da Disciplina
Geral
Capacitar o aluno com os conhecimentos bsicos do processo de desenvolvimento
de software que permitiro aprender a: analisar, projetar e implementar sistemas de
software.
Especficos
Introduzir os conceitos bsicos de projetos de software
Apresentar a linguagem de modelagem padro de mercado Unified Modeling Lan-
guage (UML) largamente utilizada para a Anlise e Projeto de sistemas de software
Apresentar um processo completo de desenvolvimento de software utilizvel com a
linguagem UML
Demonstrar as principais caractersticas das ferramentas CASE
Instalar e configurar uma ferramenta CASE
Apresentar tcnicas e ferramentas bsicas para anlise, gerenciamento e implemen-
tao de projetos de software
Desenvolver a modelagem de um estudo de caso para consolidar os conhecimentos
da disciplina
Carga Horria: 60 horas/aula.

Aula 1
INTRODUO A PROJETOS DE
INFORMTICA
Nesta aula voc estudar os conceitos bsicos de pro-

jetos de informtica e Engenharia de Software e como
a Engenharia de Software poder auxiliar no desenvolvimento e
manuteno de sistemas de software.
Bom estudo!
Objetivos da Aula
Ao final desta aula voc dever ser capaz de:

Apontar as caractersticas de um projeto de informtica;
Identificar os conceitos bsicos da Engenharia de Softwa-
re;
Identificar os objetivos da Engenharia de Software.
Contedos da Aula

Acompanhe os contedos desta aula. Se voc preferir, assi-
nale-os medida em que for estudando.
O Projeto de Informtica;
Conceitos Bsicos de Engenharia de Software;
Exerccios propostos.

1 O QUE PROJETO DE INFORMTICA
Antes de compreendermos o que um projeto de informtica, importante sa-

bermos a definio de projeto como um todo. De acordo com o Dicionrio Aurlio, h
cinco significados para a palavra projeto:
1. Idia que se forma de executar ou realizar
algo, no futuro; plano, intento, desgnio.
2. Empreendimento a ser realizado dentro de
determinado esquema: projeto administrativo;
projetos educacionais.
3. Redao ou esboo preparatrio ou provi-
srio de um texto: projeto de estatuto; projeto
de tese.
4. Esboo ou risco de obra a se realizar; plano:
projeto de cenrio.
5. Plano geral de edificao.
Analisando os significados indicados pelo Dicionrio Aurlio, podemos ento

compreender que um projeto, independente do tipo de aplicao, pode ser considera-
do como um planejamento, com menos ou mais detalhes, dependendo da sua aplica-
o, que poder auxiliar na execuo e avaliao do resultado obtido ao final de sua
execuo.
Ao analisarmos o contexto de nossas prprias vidas, podemos identificar vrios
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 necessrio sabermos: o local destino da viagem, o custo dessa viagem,
a forma de transporte, a forma de hospedagem, a melhor poca para realizao da
viagem, entre outros. Alm disso, ao planejar uma viagem de turismo, precisamos
saber quando poderemos realiz-la e tambm se temos condies 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 durao, em outras palavras, quando o incio e o fim da realizao do
projeto.
Os projetos de informtica possuem vrias caractersticas que se assemelham
a um projeto de turismo, porm no projeto de informtica como o caso do software
o produto abstrato, motivo pelo qual a elaborao e a conduo desse tipo de pro-
jeto se torna muito mais complexo devido ao grande nmero de variveis que podem
modificar a estrutura do projeto e, conseqentemente, seu resultado final.
Neste mdulo, focalizaremos principalmente a elabo-
rao e execuo de projetos para desenvolvimento
de software, porm muitas tcnicas que abordare-
mos podero ser utilizadas em outros projetos tan-
to de informtica, como um projeto de montagem de
uma rede de computadores, por exemplo, quanto de
outras reas. Em alguns casos, alguns ajustes po-
dem ser necessrios, mas em um contexto geral, a
parte de anlise e detalhamento do projeto pode ser
disseminada para outros tipos de projetos.
1.2 PRINCIPAIS CARACTERSTICAS DE UM PROJETO
As principais caractersticas de um projeto so:

Durao tempo estimado para incio 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 finalizao do projeto
A caracterstica Planejamento, alm de estar diretamente relacionada com Du-

rao e Custo, tambm ir refletir na Qualidade do projeto. Portanto, se o planejamen-
to no for desenvolvido de maneira eficiente, o sucesso do projeto estar automatica-
mente comprometido.

Fique sabendo
Atualmente, existem vrios modelos que permitem auxiliar nas ta-

refas de planejamento e gerenciamento de projetos. Os modelos
mais populares so: 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 informaes de uma grande pesqui-
sa sobre sucessos e fracassos dos projetos de software. Nesse estudo, os resultados
dos projetos so classificados da seguinte maneira:
Bem sucedidos - O projeto finalizado no prazo, dentro do oramento e
contendo todas as funcionalidades especificadas.
Comprometidos - O projeto finalizado e um software operacional entre-
gue, porm o oramento e o prazo ultrapassam os limites estipulados, e, alm
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 nmero 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 no so bem sucedidos. Podemos verificar tambm que a grande
maioria dos projetos est na categoria dos comprometidos, tiveram problemas no
planejamento como custo alm do esperado, ou ainda com uma durao muito maior
do que a estipulada.
De posse dessas informaes, podemos concluir que imprescindvel aos pro-
fissionais de informtica, em especial os desenvolvedores de software, a utilizao
das melhores tcnicas 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 trs elementos Neste contexto podemos traduzir a pala-
fundamentais mtodos ferramentas e pro- vra rebento como uma juno/unio en-
tre a engenharia de sistemas e de hardwa-
cedimentos que possibilita ao gerente o re. Com a unio destas duas engenharias
surgiu a Engenharia de Software.
controle do processo de desenvolvimento de

software e oferece ao profissional uma base para a construo de software de alta

qualidade produtivamente (PRESSMAN, 1995, p. 31).
Analisando a definio de engenharia de software feita por Pressman, pode-
mos interpret-la como um conjunto de mtodos, ferramentas e tcnicas que auxiliam
os profissionais no desenvolvimento dos projetos de software.
Mas...
Por que necessria a utilizao da Engenharia de Software nos projetos de
software?
Antes de responder esta questo, importante analisarmos um pouco alguns
dados histricos a respeito do desenvolvimento de software.
Como j sabemos, a informtica uma cincia muito nova ainda, em relao a
outras cincias como medicina e direito, por exemplo, que j existem h alguns scu-
los. Se relembrarmos os fatos histricos sobre a colonizao do Brasil, veremos que,
naquela poca, j existiam profissionais de medicina e de direito. A informtica ainda
no completou um sculo de existncia, o primeiro computador, o ENIAC, foi criado
em 1946.
Fique sabendo
O engenheiro John Presper Eckert e o fsico John Mauchly proje-

taram o ENIAC: Eletronic Numeric Integrator And Calculator. Com
18000 vlvulas, o ENIAC conseguia fazer 500 multiplicaes por se-
gundo. Os custos para a manuteno e conservao do ENIAC eram
absurdos, pois dezenas a centenas de vlvulas queimavam a cada hora e o
calor gerado por elas necessitava ser controlado por um complexo sistema de refri-
gerao, alm dos gastos elevadssimos de energia eltrica. (WIKIPDIA)
Antes do ENIAC, j havia alguns recursos e Ferramentas

de informtica, mas eram utilizadas somente por militares, que
fizeram uso dessa tenologia durante as duas grandes guerras
mundiais. Aps a criao do ENIAC, a informtica comeou a
ser utilizada em outros cenrios, como a indstria.
Na dcada de 50, deu-se incio ao software, cuja evolu-

o possvel verificar na figura 2.
Figura 2 Evoluo do Software
A primeira era da evoluo do software teve incio nos anos 1950 e se estendeu
at meados de 1965. Nesta era o software possua as seguintes caractersticas:
O desenvolvimento do software era feito sem nenhum tipo de planejamento,
at que os prazos comeassem 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 execuo de um nico programa que, por sua vez,
dedicava-se a uma nica aplicao especfica;
O software era projetado sob medida para cada aplicao e tinha distribuio
relativamente limitada;
Geralmente o projeto do software era um processo implcito, realizado no c-
rebro de algum, e a documentao muitas vezes no existia.
De acordo com as caractersticas da primeira era da evoluo do software,

podemos imaginar a complexidade que deveria ser desenvolver e depois realizar ma-
nutenes nos softwares desenvolvidos naquela poca.
A segunda teve incio em 1965 e se estendeu at 1975. Essa era foi marcada
pelas seguintes caractersticas:
A multiprogramao e os sistemas multiusurios introduziram novos concei-
tos de interao homem-mquina;
Teve incio a utilizao de tcnicas interativas;
Os avanos da armazenagem on-line levaram primeira gerao de sistemas
de gerenciamento de banco de dados;

Comearam a surgir as software houses, empresas dedicadas exclusiva-

mente ao desenvolvimento de softwares;
O software era desenvolvido para ampla distribuio num mercado interdisci-
plinar, incio do conceito de produto de software;
Os softwares eram geralmente programas desenvolvidos para mainframes e
minicomputadores;
Surgimento da manuteno de software.
Na segunda era, podemos observar que houve um salto bem grande na evo-
luo do desenvolvimento de software. Foi nessa poca que comearam a surgir as
primeiras idias para o desenvolvimento de Sistemas Gerenciadores de Banco de
Dados, tecnologia muito utilizada atualmente no desenvolvimento de software.
Nessa poca tambm comearam 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 incio em 1975 e foi at 1985, foi marcada pelas seguin-
tes caractersticas:
As redes globais, as comunicaes digitais de largura de banda elevada e a

crescente demanda de acesso instantneo 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 estaes de trabalho works-
tations de mesa.
Para suprir as necessidades de mercado, nessa poca, novos conceitos como

Sistemas Distribudos e Inteligncia Artificial comearam a surgir. J tivemos
grandes avanos, mas como a aplicao 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-
tersticas:
As tecnologias orientadas a objetos comearam a ocupar o lugar das aborda-
gens mais convencionais para o desenvolvimento de software em muitas reas
de aplicao;
As tcnicas de quarta gerao 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 inteligncia artificial finalmente sa-
ram do laboratrio para a aplicao prtica em problemas do mundo real.

De acordo com as caractersticas da quarta era da evoluo do software, pode-

mos perceber que vivemos uma nova era do desenvolvimento de software. Esta afir-
mao pode ser feita, pois os softwares desenvolvidos atualmente esto fortemente
marcados pelas seguintes caractersticas:
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;
Introduo do conceito de servios, pequenas aplicaes especficas para um
determinado fim, est se propagando;
Grande evoluo dos sistemas gerenciadores de banco de dados, permitindo
a integrao entre o banco de dados e sistemas disponveis na internet;
Preocupao com qualidade no desenvolvimento e planejamento dos softwa-
res fez surgir vrios modelos e tcnicas.
Assim, ao analisar a evoluo no desenvolvimento de software, fica mais fcil

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 ento suprir deficincias dos processos manti-
dos pelos softwares da poca. No incio, 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 satisfao dos profis-
sionais.
Sntese da Aula
Nesta aula estudamos:

Introduo ao conceito de projeto de informtica;
Principais caractersticas de projetos de informtica;
Conceito e caractersticas de Engenharia de Software;
A evoluo do desenvolvimento de Software.
Exerccios Propostos
1) Assinale a alternativa correta. Para que um projeto de software seja bem su-
cedido, imprescindvel o cumprimento das seguintes caractersticas:
a) Prazo, Qualidade, Planejamento;
b) Custo, Prazo, Planejamento;
c) Custo, Prazo, Funcionalidades;
d) Funcionalidades, Prazo, Planejamento.
2) Selecione a alternativa correta. A caracterstica de projeto que est diretamen-

te ligada s demais caractersticas e poder impactar no seu sucesso :
a) Durao

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 tcnicas, fer-
ramentas e procedimentos;
c) Disponibilizar tcnicas e ferramentas para a construo do software;
d) Disponibilizar ferramentas para o desenvolvimento de software.
3) Qual das alternativas abaixo uma caracterstica especfica da era atual de

desenvolvimento de software?
a) Utilizao de gerenciadores de banco de dados;
b) Utilizao de inteligncia artificial;
c) Utilizao de arquitetura cliente-servidor;
d) Utilizao de ambiente WEB.

Aula 2
INTRODUO A UML
Nesta segunda aula voc estudar o que modelagem

de software e qual a sua importncia dentro de um
projeto de software. Tambm vamos estudar o que a linguagem
UML, seu histrico, suas principais caractersticas 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 importncia da modelagem;
Identificar os conceitos bsicos da UML;
Descrever como a UML pode auxiliar na modelagem.
Contedos da Aula

Modelagem de Software;
Introduo a UML;
UML e o Processo de Desenvolvimento de Software;

1 MODELAGEM DE SOFTWARE
Para que possamos compreender o que e qual a importncia da modelagem

de software, vamos primeiro analisar o que o software, como surgiu e quais as suas
principais caractersticas.
De acordo com PRESSMAN (1995, p. 12), podemos definir didaticamente o
software das seguintes maneiras:
1. Instrues (programas de computador) que, quando executadas, produzem
a funo e o desempenho desejados;
2. Estruturas de dados que possibilitam que os programas manipulem adequa-
damente a informao;
3. Documentos que descrevem a operao e o uso dos programas.
Se analisarmos novamente a figura 2 (pg. 14) Evoluo do Software da

aula 1, veremos que o software surgiu com o objetivo principal de suporte s ativida-
des da informtica, porm, naquela poca, era visto como algo feito de forma artesa-
nal, sem grande importncia e poucos possuam o conhecimento de uma linguagem
de desenvolvimento. O importante mesmo, na poca, era o hardware, que tambm
detinha grande parte dos custos dentro de
A automao pode ser traduzida como
um projeto de informtica ou mesmo auto- um procedimento que utiliza as tecnolo-
mao de atividades. gias de sistemas de informao dispon-
veis para substituir atividades manuais
Com o passar do tempo, as utilidades de mo-de-obra por equipamentos, siste-
mas e mquinas com o objetivo principal
adquiridas por meio da relao hardware e
de aumento na produtividade.
software se tornaram mais expressivas e o
software comeou a se tornar uma pea fundamental para os projetos de sistemas
de informao. J no era mais possvel desenvolver de forma artesanal, pois toda
responsabilidade em torno da manipulao 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 fsico, o sof-
tware um objeto abstrato, em outras palavras, um objeto lgico. As principais carac-

tersticas que diferenciam o software do hardware so:

O sofware desenvolvido ou projetado por engenharia, no manufaturado no
sentido clssico;
O software no se desgasta;
A maioria dos softwares feita sob medida em vez de ser montada a partir de
componentes existentes.
A primeira caracterstica citada por PRESSMAN indica que, diferente de um

produto de hardware que tambm utiliza a engenharia durante o seu desenvolvi-
mento em um dado momento esse objeto passa do modelo lgico esboos e
desenhos da idia feitos no papel para algo palpvel e manufaturado, construdo em
um ambiente de produo, com auxlio de mquinas, equipamentos e pessoas desse
ambiente de produo. J no desenvolvimento do software, todo o seu desenvolvi-
mento concentrado com base na engenharia. Tambm h a fase de desenvolvimen-
to, qquando os programas e instrues so escritos, porm todas as fases de projeto
do software so baseadas em mtodos e ferramentas da engenharia de software.
A segunda caracterstica realmente perceptvel. O software jamais se desga-
ta, pode ficar ultrapassado, porm 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 diferenas na
ocorrncia 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 tendncia que deixem de ocorrer com o tempo. Porm, como j discutimos nos
itens anteriores, problemas com o gerenciamento e o desenvolvimento do software
podem ocasionar falhas, quando se solicita uma alterao no software que j est
estvel (modelo real).
A terceira caracterstica apontada por PRESSMAN sugere que o software seja
sempre desenvolvido do incio, ou seja, todos os programas e instrues so escri-
tos novamente a cada software, pois a caracterstica dos softwares, muitas vezes,
especfica. J com o hardware, componentes podem ser utilizados na sua produo,
reduzindo o tempo de produo e maximizando a qualidade do produto final. Nessa
caracterstica, porm, a produo de software tem evoludo bastante com a utilizao
da orientao a objetos, cuja programao torna possvel criar componentes de sof-
tware que permitam sua reutilizao nos prximos projetos de software. Essa uma
tendncia para o desenvolvimento de software.
De acordo com as caractersticas acima descritas, podemos interpretar o de-
senvolvimento de software como uma tarefa complexa que pode aumentar, dependen-
do da rea de negcio onde o software ir atuar e tambm do seu tamanho, conforme
a quantidade de funcionalidades que ir dispor.
Assim, para minimizar essa complexidade e auxiliar na definio das funcionali-
dades do software, mtodos, como a modelagem de sistemas, surgiram como suporte
para os projetos de software. A utilizao de um modelo supre a necessidade de uma

representao idealizada de um software a ser desenvolvido. Por meio dos modelos,

ser mais fcil compreender as funcionalidades e objetivo principal do sistema de sof-
tware, alm 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 construo naval, por exemplo, desenvolve maquetes
modelos de navios em tamanho reduzido para representar o formato do navio e
analisar os detalhes da construo final do navio. Ao construir a maquete do navio,
o engenheiro naval poder identificar vrios problemas com o projeto inicial e corrigi-
los ainda nessa fase de modelo. Imagine: se o navio fosse construdo direto, sem
que um modelo fosse desenvolvido anteriormente? Provavelmente muitos recursos
seriam disperados 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 possveis problemas ainda na fase de modelo. Essa prtica 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 razes para a utilizao

da modelagem no desenvolvimento de software:
1. Gerenciamento da complexidade;
2. Comunicao entre as pessoas envolvidas;
3. Reduo dos custos no desenvolvimento;
4. Predio 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 possvel definir quais tcnicas e procedimentos permitiro
gerenciar e reduzir a complexidade do software. Alm disso, com o modelo, ser

mais fcil discutir com uma equipe e identificar as melhores prticas e/ou ferramentas
necessrias para o seu desenvolvimento.
Defender uma idia com um modelo j proposto tambm se torna muito mais
fcil e simples do que faz-lo com uma idia que ainda est no
pensamento. Isso porque, ao criar o modelo, muitas alteraes e
melhorias podero ser identificadas durante a sua construo. Ou
seja, j na criao do modelo, o prprio autor identifica problemas
que poderiam surgir e j faz as correes necessrias para apre-
sentar a idia concreta aos demais membros da equipe.
A reduo do custo, por sua vez, pode ser identificada conforme o tempo gas-
to no desenvolvimento de um software que no foi corretamente definido. Imagine
ir desenvolvendo um projeto apenas de acordo com o que se acredita ser a forma
correta. Ao apresentar a verso final do software para o usurio, bem possvel que
as seguintes frases sejam ditas: No era bem isso que eu queria ou No foi isso que
eu pedi. Assim, para evitar esse tipo de constrangimento, tanto para o desenvolvedor
quanto para o usurio, o ideal construir um modelo dispendendo muito menos tempo
do que o desenvolvimento completo do sistema, e realizar a validao do modelo com
o usurio, antes do incio da construo do sistema. Isso garantir maior sucesso na
entrega do software.
Por fim, a predio do comportamento futuro do sistema pode ser considerada
como a principal razo para a construo do modelo de software, pois, com o modelo,
ser possvel mapear todo o funcionamento e tambm a interao entre as funciona-
lidades do software a ser desenvolvido.
1.3 Evoluo da Modelagem de Software
A modelagem uma prtica que vem acompanhando a evoluo do desenvol-

vimento de software. Por ser uma prtica comum em outras engenharias, a modela-
gem tambm foi absorvida pela engenharia de software para dar suporte e permitir a
anlise de detalhes do software, antes mesmo de sua produo.
BEZERRA (2002, p. 12) faz um breve resumo histrico da evoluo da mode-
lagem de sistemas:

Dcadas 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- Este termo significa direto ao
seqentemente, as tcnicas de modelagem assunto ou direto ao que inte-
ressa.
eram mais simples: era a poca dos fluxogra-
mas e dos diagramas de mdulos.
Dcada de 1970 computadores mais avanados e acessveis comearam
a surgir. Houve grande expanso do mercado computacional. Sistemas mais
complexos comeavam a surgir. Por conseguinte, modelos mais robustos fo-
ram propostos. Surgem a Programao Estruturada e o Projeto Estruturado.
Os autores Larry Constantine e Edward Yourdon so grandes colaboradores
nessas tcnicas.
Dcada de 1980 os computadores se tornaram ainda mais avanados e
baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou
a produo de sistemas de softwares mais complexos. A Anlise Estruturada
surgiu no incio desse perodo, com os trabalhos de Edward Yourdon, Peter
Coad, Tom DeMarco, James Martin e Chris Gane.
Incio da dcada de 1990 perodo em que surge um novo paradigma de
modelagem, a Anlise Orientada a Objetos. Grandes colaboradores desse pa-
radigma so Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rum-
baugh, Grady Booch e Ivar Jacobson.
Fim da dcada de 1990 o paradigma da orientao a objetos atinge sua
maturidade. Os conceitos de padres de projeto, frameworks, componentes
e qualidade comeam a ganhar espao. Surge a Linguagem de Modelagem
Unificada UML.
2 Introduo a UML
A UML (Unified Modeling Language) uma linguagem-padro para

a elaborao da estrutura de projetos de software. Pode ser
empregada para a visualizao, a especificao, a construo
e a documentao de artefatos que faam uso de sistemas

complexos de software (BOOCH, 2005, p. 13).

A construo da UML teve muitos contribuintes, mas os principais foram: Grady
Booch James Rumbaugh e Ivar Jacobson. Trs pesquisadores freqentemente cha-
mados de os trs amigos (BEZERRA, 2002, p. 13).
Como vimos no tpico 1.3, sobre a evoluo da modelagem de sistemas, du-

rante a dcada de 1990, vrios pesquisadores desenvolveram tcnicas de modela-
gem com base na orientao a objetos. Os trs amigos, que tambm estavam en-
volvidos em muitas dessas tcnicas, 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 padro pelo rgo
internacional que rege os padres na rea de orientao a objetos, o OMG Object
Management Group, http://www.omg.org
A partir de ento, a UML tem tido grande aceitao pela comunidade de de-
senvolvedores de software. Atualmente, a linguagem est na sua segunda verso
conhecida como UML 2 -, e continua em constante desenvolvimento. Empresas
como: HP, IBM, Oracle, Microsoft, entre tantas outras, tem dado especial ateno na
divulgao e evoluo da linguagem.
2.2 Caractersticas da UML
A UML uma linguagem visual para modelar sistemas orientados a objetos.

Significa que a UML composta de elementos grficos visuais que podem ser uti-
lizados na modelagem e, permitem representar os conceitos do paradigma da orien-
tao 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 grficos da UML, possvel visualizar, de forma mais
detalhada, como ser o funcionamento do software e quais sero os objetos necess-
rios para a construo do sofware.
Assim como a linguagem dispe de elementos grficos, que possibilitam me-
lhor visualizao do funcionamento do software,
Um artefato pode ser traduzido
existem tambm artefatos que permitem detalhar como um documento de modela-
gem de orientao a objetos.
o funcionamento de forma textual. Existe um ditado
que diz: Uma figura vale por mil palavras, porm em alguns casos, pode-se utilizar
uma semntica para interpretar um smbolo UML.
Por ser uma linguagem-padro, a UML tem sido absorvida por vrias ferramen-
tas comerciais para dar suporte e facilitar o trabalho dos desenvolvedores durante a
construo do software. Algumas ferramentas permitem, por meio dos modelos UML,
a gerao automtica de partes do cdigo-fonte do software. Em alguns casos, at
o inverso tambm possvel prtica conhecida como engenharia reversa -, onde a
ferramenta poder gerar o modelo UML por meio de um cdigo- fonte do software. A
prtica de engenharia reversa, porm, no muito aconselhvel, pois o ideal que do
modelo se parta para a construo final, e no o inverso, evitando problemas, alguns
j vistos nos tpicos anteriores, que podem surgir quando o software construdo 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 prtica a ser
utilizada.

Fique sabendo
O termo engenharia reversa tem suas origens no mundo do

hardware. Uma empresa desmonta um hardware comercializado,
num esforo para entender os segredos de projeto e manufatura do
concorrente. A engenharia reversa para o software muito semelhante,
porm, na maioria dos casos, o software que ir passar por este processo
da prpria empresa e tem como objetivo principal gerar a documentao de
partes do cdigo que foram implementadas muitas vezes direto no cdigo, sem
desenvolvimento de um modelo especfco. (PRESSMAN, 1995, p. 900)
Com base nos artefatos gerados por meio dos elementos da UML, possvel
tambm possuir uma documentao a respeito do funcionamento do software.
A UML abrange a documentao da arquitetura do sistema e de todos os seus deta-
lhes proporciona uma linguagem para a expresso de requisitos e para a realizao
de testes. Tambm oferece uma linguagem para a modelagem das atividades de
planejamento do projeto e de gerenciamento de verses.
A UML foi criada especificamente para a rea de modelagem de sistemas de
software, porm seus elementos e suas tcnicas permitem sua utilizao para mo-
delagem de outros projetos sistemas que no de software. Depois de sua aprovao
como um padro, a linguagem, segundo Booch (2005, p.17), vem sendo empregada
em diversas reas de conhecimento:
Sistemas de informaes corporativos;
Servios bancrios e financeiros;
Telecomunicaes;
Transportes;
Defesa/espao areo;
Vendas de varejo;
Eletrnica mdica;
Cientficos;
Servios distribudos baseados na WEB.
A UML independente tanto de linguagens de programao quanto de proces-

so de desenvolvimento. Significa que pode ser utilizada para a modelagem de siste-

mas, no importando qual a linguagem de programao a ser utilizada na implemen-

tao do sistema, ou qual a forma processo de desenvolvimento adotado. Esse
um fator importante para a utilizao da UML, pois diferentes sistemas de software
requerem diferentes abordagens de desenvolvimento.
2.3 Vises de um Sistema
Como j dissemos, um sistema de software algo complexo. Desta forma,

muitas vezes ser necessrio a criao de mais de um modelo, cada um com o foco
em uma determinada funcionalidade ou detalhe do sistema, para que seja possvel
conceber a abrangncia do software. Para isso, os autores da UML os trs amigos
sugerem a utilizao das: Vises do Sistema, que podem ser classificadas da se-
guinte forma:
Viso de Caso de Uso: descreve o sistema de um ponto de vista externo,
como um conjunto de interaes entre o sistema e os agentes externos ao
sistema. Esta viso criada inicialmente e direciona o desenvolvimento das
outras vises do sistema.
Viso de Projeto: enfatiza as caractersticas do sistema que do suporte,
tanto estrutural quanto comportamental, s funcionalidades externamente vis-
veis do sistema.
Viso de Implementao: abrange o gerenciamento de verses do sistema
controle de alteraes -, construdas por meio do agrupamento de mdulos
componentes e subsistemas.
Viso de Implantao: corresponde distribuio fsica do sistema em seus
subsistemas e conexo entre essas partes.
Viso de Processo: enfatiza as caractersticas de concorrncia paralelis-
mo -, sincronizao e desempenho do sistema.
claro que, dependendo das caractersticas do projeto, nem todas as vises

precisaro ser utilizadas. Sua utilizao vai depender do tamanho do projeto e da
complexidade. Esta tambm uma das grandes vantagens da UML, que permite ser
flexvel de acordo com a necessidade de cada projeto. A interao entre as vises

demonstrada na figura 5.
Figura 5 Vises 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 negcio 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
so considerados: fracassados projetos que no so entregues e comprometidos
projetos que so entregues porm 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-
finio de processos de desenvolvimento de software.
Um processo de desenvolvimento de software ou simplesmente, processo de
desenvolvimento compreende todas as atividades necessrias para definir, desen-
volver, testar e manter um produto de software (BEZERRA, 2002, p. 19).
Os principais objetivos do processo de desenvolvimento de software so:
Definio das atividades que sero executadas ao longo do projeto;
Definio de quando, como e por quem as atividades sero executadas;
Definio de pontos de controle para verificar o andamento do desenvolvi-
mento;

Padronizar a forma de desenvolver software em uma organizao.
A UML uma grande aliada do processo de desenvolvimento. Por ser uma lin-
guagem padro, permite que vrias 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
captulo 5.
Sntese da Aula
Nesta aula estudamos,
A definio de software e como surgiu;

O que e qual a importncia da modelagem de sistemas de software;
Os conceitos bsicos da UML;
O que Processo de Desenvolvimento de Software e como a UML pode con-
tribuir para este processo.
Exerccios Propostos
1) Assinale a alternativa incorreta:

a) O software surgiu com o objetivo de auxiliar o hardware nas atividades de manipu-
lao da informao;
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 lgico.

2) Assinale a alternativa correta:

a) A curva de falhas do software considerada pequena no incio do desenvolvimento,
porm tende a crescer com o passar do tempo;
b) A curva de falhas do hardware considerada pequena no incio do desenvolvimen-
to, porm tende a crescer com o passar do tempo;
c) A curva de falhas do hardware considerada grande no incio do desenvolvimento,
se estabiliza aps a entrega do projeto, porm tende a crescer com o passar do tem-
po;
d) A curva de falhas do software considerada grande no incio do desenvolvimento,
se estabiliza aps a entrega do projeto, porm tende a crescer com o passar do tem-
po;
3) Assinale a alternativa incorreta. As vantagens na utilizao da modelagem

so:
a) Reduo do prazo de desenvolvimento;
b) Gerenciamento da complexidade;
c) Visualizao abrangente do funcionamento do sistema;
d) Reduo do custo de desenvolvimento;
4) A UML surgiu na dcada de (nica escolha):

a) 1960
b) 1970
c) 1980
d) 1990
5) Assinale a alternativa incorreta. Por meio da UML possvel:

a) Visualizar o funcionamento do sistema de software;
b) Escrever as instrues dos programas que iro compor o sistema de software;
c) Especificar o funcionamento do sistema de software de maneira textual;
d) Construir vrios modelos que permitiro interpretar o funcionamento do sistema de
sofware.

Aula 3
INTRODUO A FERRAMENTA
CASE
Nesta aula voc estudar sobre os conceitos bsicos

que envolvem as ferramentas CASE e quais so os ti-
pos de ferramentas disponveis para suporte ao desen-
volvimento de projetos de software. Tambm estudar a ferramenta
CASE que estaremos utilizando na disciplina que possibilitar a
criao 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.
Contedos da Aula

Introduo Ferramenta CASE;
Utilizando Ferramenta CASE para Anlise e Modelagem
de um Projeto;

1 INTRODUO A FERRAMENTAS CASE
A sigla CASE significa: Computer-Aided Software Engineering, em portu-

gus: Engenharia de Software auxiliada por computador. O significado do nome CASE
sugere a seguinte situao: desenvolver sistemas de software, utilizando as prticas
da Engenharia de Software e os recursos disponveis por meio do computador.
Esses recursos, disponveis por meio do computador, so 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 disponveis no mercado e com
finalidades diversas. Conforme Bezerra (2002, p.39), as principais caractersticas das
ferramentas CASE so:
Criao de diagramas e manuteno da consistncia entre os diagramas;
Gerao de cdigo-fonte a partir de diagramas e gerao de diagramas a
partir do cdigo-fonte engenharia reversa;
Depurao de cdigo-fonte: ferramentas que permitem encontrar erros de
lgica em partes de um programa;
8 Relatrios de testes: ferramentas que geram relatrio informando sobre par-
tes de um programa que no foram testadas;
Testes automticos: ferramentas que realizam testes automaticamente no sis-
tema;
Gerenciamento de verses: ferramentas que permitem gerenciar as diversas
verses dos artefatos de software gerados durante o ciclo de vida de um sis-
tema;
Verificao de desempenho: averiguar o tempo de execuo de mdulos de
um sistema, assim como o trfego de dados em sistemas em rede;
Verificao de erros em tempo de execuo;
Gerenciamento de mudanas nos requisitos.
Alm das caractersticas citadas por BEZERRA, existem tambm 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, definio de custos do projeto, acompanhamento de prazos e custos do pro-
jeto, alocao de profissionais para a execuo 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 questo, vamos utilizar a seguinte analogia: Um me-
cnico possui em sua oficina inmeras 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 permitiro desenvol-
ver o trabalho de forma mais produtiva. O aumento da produtividade ir, conseqen-
temente, resultar em aumento da qualidade das atividades.
Outra vantagem que pode ser verificada na utilizao das ferramentas CASE
a melhoria das comunicaes e documentaes do projeto de software, devido
maior possibilidade de preciso, consistncia e representaes claras de um sistema
de software.
A padronizao de modelos e atividades tambm poder ser adquirida por
meio das ferramentas CASE, porque algumas definies, em relao a metodologias,
tcnicas e procedimentos, devero ser empregadas no processo de desenvolvimento
de software, ao adotar uma ferramenta CASE como suporte no desenvolvimento de
projetos.
Mas a adoo de uma ou um conjunto de ferramentas CASE no uma tarefa
fcil, 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
no estiverem capacitados para sua utilizao.
Portanto, imprescindvel, antes da adoo dessas ferramentas, considerar os
seguintes itens:

Custo de longo prazo da manuteno das ferramentas CASE (potencialmente

ao longo do ciclo de vida do sistema desenvolvido com a ferramenta);
Lanamento freqente de nova tecnologia;
Custos contnuos para treinamento de novos funcionrios e atualizao dos
funcionrios existentes j treinados;
Reestruturao das ferramentas.
O sucesso ou falha na adoo das ferramentas CASE depende muito da habi-

lidade de uma organizao para gerenciar custos de curto e longo prazo. As organi-
zaes que tm tido cuidado com esses tipos de problemas no processo de adoo,
apresentam as melhores chances de sucesso.
O SEI - Software Engineering Institute - Instituto de Engenharia de Software
-, desenvolveu um processo de adoo de ferramentas CASE, cujo modelo define
seis estgios:
Conscincia;
Comprometimento;
Seleo;
Implementao de testes;
Estratgia de implementao;
Rotinizao
Os estgios sugeridos e a forma de aplicao podem ser observados na figura
6.
Figura 6 Processo sugerido para adoo das ferramentas CA

1.3 Tipos de Ferramentas CASE
A engenharia de sofware auxiliada por computador pode ser to simples quanto

uma nica ferramenta que suporte uma atividade de engenharia de software especfi-
ca ou to complexa quanto um ambiente completo que abranja ferramentas, banco
de dados, pessoas, hardware, rede, sistemas operacionais, padres e uma infinidade
de outros componentes (PRESSMAN, 1995, p. 947).
Um ambiente CASE, como vimos na definio 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 atuao do CASE
dentro de um ambiente integrado.
Figura 7 Ambiente CASE
As ferramentas CASE podem ser classificadas por funo, por seus papis
como instrumentos para os gerentes e para o pessoal tcnico pelo uso que tm nas
vrias 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 mtricas e gerenciamento;
Ferramentas de apoio;
Ferramentas de documentao;

Ferramentas de software bsico;

Ferramentas de garantia da qualidade;
Ferramentas de banco de dados;
Ferramentas de Anlise e Projeto;
Ferramentas de Programao;
Ferramentas de prototipao so
Ferramentas de Integrao e Teste; ferramentas que permitem ao de-
Ferramentas de Prototipao; senvolvedor criar um prottipo
modelo que ir representar
Ferramentas de Manuteno; o layout das telas do sistema de
Ferramentas de Engenharia Reversa; software.
Ferramentas de Reengenharia;
Ferramentas de Estrutura.
Nesta disciplina, utilizaremos a ferramenta CASE: JUDE que auxilia na fase de

anlise e projeto do sistema de software.
2 UTILIZANDO FERRAMENTA CASE PARA ANLISE E PROJETO
As ferramentas de anlise e projeto possibilitam que o engenheiro de software

crie um modelo do sistema que ser construdo (PRESSMAN, 1995, p. 958).
No modelo sugerido por PRESSMAN, ser possvel demonstrar informaes
como: funcionalidades do sistema, componentes que sero utilizados pelas funcio-
nalidades, interao entre o usurio do sistema e as funcionalidades, forma como os
dados gerados pelo sistema sero armazenados, entre outros.
Na verdade, sero criados vrios modelos, cada um com uma finalidade espe-
cfica, porm a unio destes modelos ir representar o contexto geral e abrangncia
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 anlise e projeto, que permite desenvolver a
modelagem de sistemas orientados a objetos, utilizando a linguagem padro UML.

Atualmente, a ferramenta possui trs verses:

1. Community verso gratuita, basta realizar um cadastro para ter acesso ao
arquivo de instalao;
2. Professional uma verso paga, pois disponibiliza mais recursos de inte-
grao com outras ferramentas;
3. Server tambm uma verso paga que possui recursos como controle de
verso.
Nesta disciplina utilizaremos a verso Community da ferramenta. uma verso
gratuita, mas possui todos os recursos necessrios 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 instalao da ferramenta, ser necessrio aces-

sar o site e realizar um cadastro. Efetuando o cadastro, ser habilitado um link para
acesso ao arquivo de instalao da ferramenta. Aps o download do arquivo de ins-
talao, basta execut-lo e seguir as instrues de instalao.
Os passos para o processo de instalao so:
1. Acesse o site:
https://jude.change-vision.com/jude-web/product/community.html;
2. Clique no boto: [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 boto: [New Registration]

para realizar o seu cadastro;
Figura 9 Tela de acesso ao cadastro
4. Na prxima tela ser solicitada a leitura do termo de contrato e o aceite dos termos
do contrato. Para dar continuidade, clique no boto: [I agree];
5. Em seguida, ser mostrada a tela de cadastro (figura 10). Preencha todos os cam-
pos obrigatrios com ateno e, ao final, clique no boto para confirmao do cadas-
tro, boto: [Confirm];
Figura 10 Tela de cadastro
6. Ao clicar no boto de confirmao, ser mostrada uma tela para que voc possa
validar os dados informados. Se os dados estiverem corretos, clique no boto: [Re-

gister] para efetivar o cadastro;
7. A confirmao do cadastro ser encaminhada para o e-mail informado na tela de

cadastro. Para ter acesso ao arquivo de instalao da ferramenta, clique no boto:
[OK] da tela de confirmao de cadastro e informe o login e senha cadastrados;
8. Na tela seguinte, aps a autenticao do seu login e senha, clique no boto: [Down-
load], conforme mostra a figura 11;
Figura 11 Tela de acesso dos membros JUDE
9. Na prxima tela, sero disponibilizadas todas as verses do JUDE para download.

As verses pagas Professional e Server iro exigir o preenchimento da licena
aps a instalao. Portanto, a verso que utilizaremos a Community. Como o
JUDE uma ferramenta desenvolvida em Java, necessrio que voc possua em
seu computador a mquina virtual Java instalada, caso contrrio, voc poder pegar
o arquivo de instalao do JUDE que vem com a mquina virtual embutida;
10. Se voc j possui a mquina virtual Java instalada em seu computador, faa do-
wnload do primeiro arquivo listado na figura 12. Caso contrrio, se voc no possui a
mquina virtual Java instalada, faa o download do segundo arquivo da figura 12;

Arquivo 1
Arquivo 1
Figura 12 Tela de acesso dos membros JUDE
11. Na prxima tela, clique no boto: [Download] para iniciar o processo de transfern-
cia do arquivo de instalao;
12. Finalizao o download, clique duas vezes em cima do arquivo: jude-community-

5_2b1-setup.exe para iniciar a instalao. Selecione o idioma ingls e clique no bo-
to: [Next], conforme mostra a figura 13;
Figura 13 Tela 1 da instalao da ferramenta
13. Na tela seguinte, clique no boto: [Next], conforme mostra a figura 14;

14. Na tela seguinte, sero mostrados os termos de contrato. Selecione o aceite e

clique no boto: [Next], conforme mostra a figura 15;
15. Na tela seguinte, ser solicitado o local para a instalao da ferramenta. Se prefe-
rir, deixe o local sugerido e clique no boto: [Next], conforme mostra a figura 16;
16. A prxima seguinte mostra o nome que ser includo no menu iniciar. Deixe o pa-
dro e clique no boto: [Next], conforme indica a figura 17;

17. A prxima tela seguinte questiona se voc deseja: (1) incluir um cone da ferra-
menta no desktop, (2) incluir um cone no Quick Launch acesso rpido -, (3) associar
os arquivos com extenso: .jude com a ferramenta. Deixe o padro e clique no boto:
[Next], conforme mostra a figura 18;
18. Conforme mostra a figura 19, a prxima tela mostrar as informaes seleciona-
das at agora. Valide as informaes e clique no boto: [Install] para iniciar a instala-
o da ferramenta.
19. A instalao ser iniciada conforme mostra a figura 20. Aguarde at o final da
instalao.

20. Finalizada a instalao, ser mostrada a tela conforme a figura 21. Clique no bo-
to: [Finish] e a ferramenta JUDE ser inicializada.
21. O ambiente de trabalho da ferramenta JUDE pode ser visualizado na figura 22.
Nas prximas aulas, veremos mais detalhes sobre a utilizao da ferramenta.
Figura 22 rea de trabalho da ferramenta JUDE

Sntese da Aula
Os conceitos bsicos sobre ferramentas CASE;

Os tipos de ferramentas CASE existentes;
O que JUDE;
Os passos para a instalao da ferramenta JUDE.

Exerccios Propostos
1) Assinale a alternativa incorreta. caracterstica das ferramentas CASE:

a) Definio das atividades do projeto;
b) Depurao do cdigo-fonte;
c) Criao e manuteno de diagramas;
d) Realizao de testes automticos.
2) O principal objetivo das ferramentas CASE (apenas uma alternativa est

correta):
a) Auxiliar na gerao do cdigo-fonte;
b) Aumentar a produtividade;
c) Solucionar os problemas de qualidade e produtividade;
d) Auxiliar na definio das tarefas.
3) Assinale a alternativa incorreta, antes de adotar um conjunto ou uma nica

ferramenta CASE aconselhvel observar:
a) A linguagem de programao que utilizada;
b) O custo da ferramenta CASE;

c) Os recursos disponibilizados pela ferramenta CASE;

d) O ambiente para a integrao 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 anlise e projeto;
d) Ferramenta para programao.

Aula 4
CONHECENDO OS PRINCIPAIS
DIAGRAMAS UML
Nesta quarta aula, vamos estudar quais so os ele-

mentos da UML e os principais diagramas utilizados
na modelagem de sistemas de software. Alm disso,
veremos tambm a funo de cada diagrama e sua representao
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.
Contedos 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 orientao
a objetos, portanto, para melhor entendimento deste e dos prximos captulos,
imprescindvel possuir o conhecimento bsico do paradigma da orientao a objetos.
No apndice 1 (final deste livro) est disponvel um resumo com os principais concei-
tos da Orientao a Objetos.
A UML composta dos seguintes elementos:
Itens;
Relacionamentos;
Diagramas.
Os itens so os elementos utilizados nos diagramas para ilustrar com detalhes

o objetivo de um modelo. Os relacionamentos so, como o prprio nome sugere, os
relacionamentos entre os itens de um modelo e os diagramas, por sua vez, so os
elementos que agrupam e permitem a visualizao dos itens e seus relacionamentos.
Um modelo de sistema de software pode conter um ou mais diagramas UML.
Os itens so classificados da seguinte forma:
Itens estruturais;
Itens comportamentais;
Itens de agrupamentos;
Itens anotacionais.
Os itens estruturais so considerados a parte esttica dos modelos da UML.

So exemplos de itens estruturais:
Classes so descries de conjuntos de objetos que compartilham os mes-
mos atributos, operaes, relacionamentos e semntica;
Interfaces uma coleo de operaes que especificam servios de uma
classe ou componente;
Casos de Uso descrio de seqncias de aes realizadas pelo sistema

que proporciona valor para um determinado ator.
Os itens comportamentais so considerados a parte dinmica dos modelos

da UML. Representam comportamentos no tempo e no espao. So exemplos de
itens comportamentais:
Mensagens mostram as interaes entre os objetos, classes;
Estados definem os comportamentos que os objetos e classes podem as-
sumir ao longo do sistema;
Aes so as aes desempenhadas pelos objetos e classes do sistema.
Os itens de agrupamento so as partes organizacionais dos modelos UML.

Existe apenas um tipo principal de itens de agrupamento, os pacotes. Um pacote
um mecanismo que permite a organizao dos itens estruturais e comportamentais.
Por fim, os itens anotacionais so as partes explicativas dos modelos da UML. So
os comentrios includos nos modelos e que permitem descrever, esclarecer e/ou
fazer alguma observao sobre qualquer elemento utilizado no modelo. A tabela 1
ilustra os elementos grficos que representam os itens da UML.
Tabela 1 Itens da UML

Classificao do Item Nome Figura
Estrutural Classe
Ou
Estrutural Interface

Estrutural Caso de Uso
Comportamental Mensagens
Comportamental Estados
Comportamental Aes / Atividades
Agrupamento Pacotes
Anotacional Notas
2 Diagramas UML
Um diagrama apresentao grfica de um conjunto de elementos da UML: os

itens e relacionamentos. Os diagramas so desenhados para permitir a visualizao
de um sistema sob diferentes perspectivas ou vises do sistema. Retorne aula 2
(figura 5) para observar as vises do sistema.
O diagrama UML ir representar uma viso parcial, em outras palavras, o mo-
delo dos elementos que compe 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 atuao do sistema e da complexidade
do negcio. Um mesmo elemento UML, porm, poder ser compartilhado em mais de
um diagrama, possibilitando melhor integrao entre os modelos.
Atualmente, na verso dois, a UML disponibiliza treze diagramas que permitem
realizar qualquer tipo de combinao de itens e relacionamentos, alm de possibilitar

a criao de diversas vises como modelo para os projetos de software. No neces-

srio utilizar os treze diagramas para todos os projetos de software desenvolvidos, a
premissa da escolha pelo diagrama e pelo nvel de detalhamento dos modelos deve
partir da complexidade do software a ser construdo. Quanto maior a complexidade,
maior deve ser o nvel de detalhamento dos modelos.
Os treze diagramas da UML 2 so:
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 seqncias;
7. Diagrama de comunicaes;
8. Diagrama de grfico de estados;
9. Diagrama de atividades;
10. Diagrama de implantao;
11. Diagrama de pacote;
12. Diagrama de temporizao;
13. Diagrama de viso geral da interao.
Nesta disciplina estudaremos apenas os principais diagramas UML, so eles:

1. Diagrama de classes;
2. Diagrama de casos de uso;
3. Diagrama de seqncias;
4. Diagrama de grfico de estados;
5. Diagrama de atividades.
2.2 Diagrama de classes
Os diagramas de classes so os diagramas encontrados com maior freqncia

na modelagem de sistemas orientados a objetos. Um diagrama de classes mostra um
conjunto de classes, interfaces e colaboraes, alm de seus relacionamentos.

Os diagramas de classes so compostos pelos seguintes elementos:

Classes;
Interfaces;
Relacionamentos.
Esses so os elementos bsicos para a composio de um diagrama de clas-

ses, porm, assim como nos demais diagramas, poder conter: notas itens anota-
cionais -, e tambm pacotes itens de agrupamento.
Uma classe a descrio de um conjunto de objetos que compartilham os mesmos

atributos, operaes 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 so representadas por um retngulo dividido em trs compartimentos:
nome da classe, atributos e operaes. A figura 23 ilustra o formato de uma classe.
Figura 23 Formato de uma classe
Os relacionamentos exibidos em um diagrama de classes tm como objetivo

ligar as classes e interfaces entre si, criando relaes entre essas entidades. O rela-
cionamento representado como um caminho, em que cada relacionamento possui
linhas diferentes, para melhor visualizao. H trs tipos de relacionamentos na UML.
A tabela 2 demonstra quais so os tipos de relacionamentos existentes, a funo de
cada relacionamento e seu elemento grfico de representao.

Tabela 2 Tipos de Relacionamentos
Nome Funo Representao

Elemento grfico: seta aberta tracejada Exem-
plo:
Relacionamento entre dois itens,
a alterao no item independente
Dependncia
pode afetar a semntica funcio-
namento do item dependente. Notao:
A classe Dependente depende estruturalmente
da classe Independente.
Relacionamento estrutural entre Elemento grfico: linha simples
classes que descrevem um con- Exemplo:
junto de ligaes, em que as liga-
es so conexes entre objetos
Associao que so instncias das classes. A
agregao um tipo especial de
associao, representando um Notao:
relacionamento estrutural entre o Um departamento possui um ou mais funcion-
todo e suas partes. rios na sua hierarquia.
Elemento grfico: seta fechada
Exemplo:
Relacionamento de um elemento
mais geral e outro mais espec-
Generaliza- fico. Os objetos da classe-filha
o podem ser utilizados em qualquer
lugar onde a classe-me ocorra,
mas no o contrrio.
Notao:
A classe: Atleta a classe-me.
As classes: Nadador e Tenista herdam a estru-
tura atributos e operaes da classe Atleta.
Elemento grfico: classe ligada a uma associa-

So classes ligadas a associa- o por uma linha tracejada
es, em vez de estarem liga- Exemplo:
das a outras classes. Esse tipo
Classes Asso- de classe normalmente aparece
ciativas quando duas ou mais classes
esto associadas e necessrio
manter informaes sobre asso-
ciao.
Classe associativa = Emprego

Os relacionamentos do tipo: Associao possuem ainda algumas caracters-

ticas que permitem um detalhamento maior no relacionamento entre duas classes.
Estas caractersticas esto descritas na tabela 3.
Tabela 3 Caractersticas da Associao

Caracters-
Funo Representao
tica
Uma associao pode ter um
nome, que pode ser utilizado para
Nome
descrever a natureza do relacio-
namento.
Quando uma classe est em uma

Papel associao, possui um papel es-
pecfico neste relacionamento.
importante determinar a quan-

tidade (multiplicidade) de objetos
que podem ser conectados pela
Multiplicidade
instncia de uma conexo. A ta-
bela 4 ilustra a simbologia para re-
presentar as multiplicidades.
um tipo especial de associao

que ilustra a associao todo/par-
Agregao te. Toda ao realizada sobre a
classe todo afetar as classes
partes.
A composio um tipo especial

de agregao - agregao por va-
lor. Semanticamente equivalente
a um atributo.
A remoo do todo implica na re- Classe Pessoa
moo das partes e o acesso s
Composio
partes restrito ao todo. Significa
que as classes/objetos indicadas
como partes de uma composi-
o no estaro acessveis ex-
ternamente, somente por meio da
classe/objeto todo.
Classe Pessoa depois de utilizar composio

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 so utilizados para

Os requisitos funcionais e no-
fazer a modelagem da viso esttica de um sis- funcionais sero discutidos com
mais detalhes nos captulos 5 e
tema. Essa viso oferece principalmente suporte
6.
para os requisitos funcionais de um sistema os
servios que o sistema dever fornecer aos usurios finais (BOOCH, 2005, p. 109).
As principais caractersticas dos diagramas de classes so:
Representar os dados e funes tratados pelo sistema;
Representar a forma como os dados sero armazenados de acordo com a
orientao 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

2.3 Diagrama de casos de uso
Por meio do diagrama de casos de uso, possvel modelar os aspectos din-

micos de um sistema de software. Os diagramas de caso de uso tm um papel im-
portante na modelagem do comportamento de um sistema, por meio dele possvel
identificar de forma visual as funcionalidades do sistema e a interao destas funcio-
nalidades com o usurio final.
Por utilizar uma representao grfica simples e uma linguagem natural, o dia-
grama de casos de uso facilita a comunicao entre desenvolvedores e usurios.
um diagrama bem importante, pois direciona as tarefas posteriores do ciclo de vida do
sistema de software.
Os diagramas de caso de uso so 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 tambm
pode conter elementos como: notas e pacotes.
A fronteira do sistema ou assunto exibido como um retngulo que agrupa os
casos de uso e seus relacionamentos com os atores e demais casos de uso.
Um caso de uso a especificao de uma seqncia de interaes 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 ento, detalhadamente em um formato textual. A UML no define o formato
e o grau de abstrao a serem utilizados na descrio de um caso de uso, porm exis-
tem alguns modelos que j esto popularizados entre a comunidade UML. A tabela 5
demonstra um dos modelos utilizados para a definio textual dos casos de uso de um
sistema.

Tabela 5 Documentao de Caso de Uso

Caso de Uso: Visualizar Avaliaes
Aluno visualiza avaliao que recebeu notas e freqncia nas turmas
Sumrio:
de um semestre letivo.
Ator Primrio: Aluno
Ator Secundrio: Professor
Pr-Condies: O aluno est identificado pelo sistema.
1. O aluno solicita a visualizao das avaliaes para as disciplinas em
que participou.
2. O sistema exibe os semestres letivos nos quais o aluno se inscreveu
em pelo menos uma disciplina.
Fluxo Principal: 3. O aluno seleciona os semestres letivos cujas avaliaes deseja visu-
alizar.
4. O sistema exibe uma lista de avaliaes agrupadas por semestres
letivos selecionados e por turma.
5. O aluno visualiza as avaliaes e o caso de uso termina.
Aluno sem inscrio
1. No h semestre letivo no qual o aluno tenha participado em alguma
Fluxo de Exceo (2):
disciplina.
2. O sistema reporta o fato e o caso de uso termina.
Ps-Condies: O aluno obteve as avaliaes que desejava visualizar.
Fonte: BEZERRA, 2002, p. 82
A tabela 5 ilustra, de maneira geral, um modelo que pode ser utilizado para
a documentao de casos de uso, mas como a UML no define um formato para
a documentao textual, importante conhecer a funo de cada item utilizado na
documentao exemplo e definir quais so os itens utilizados em seus projetos de
software.
A funo 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 tambm dever aparecer no diagrama de casos de uso.
Sumrio uma pequena descrio do caso de uso, funcionalidade. Deve ser
breve e possuir no mximo duas frases.
Ator Primrio o nome do ator que inicia o caso de uso.
Ator Secundrio os nomes dos demais atores participantes do caso de
uso, se existirem.
Pr-Condies define as hipteses que so assumidas como verdadeiras

para que o caso de uso tenha incio.

Fluxo Principal corresponde descrio da seqncia 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 alcanar o seu objetivo. Esses fluxos podem ser utlizados tambm
para descrever situaes de escolha exclusivas entre si em que h diversas
alternativas e somente uma deve ser realizada.
Fluxos de Exceo correspondem descrio das situaes de exceo,
que descrevem o que acontece quando algo inesperado ocorre na interao
entre ator e caso de uso por exemplo, quando um usurio realiza alguma
ao invlida.
Ps-Condies descreve o estado que o sistema alcana aps 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 no fazem parte do sistema.
E o termo interage significa que um ator troca - envia e/ou recebe - informaes com
o sistema.
Os atores podem ser classificados da seguinte forma:
Pessoas Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc.;
Organizaes Empresa Fornecedora, Agncia de Impostos, Administrado-
ra de Cartes, etc.;
Outros Sistemas Sistema de Cobrana, Sistema de Estoque de Produtos,
etc.
Equipamentos Leitor de Cdigo de Barras, Sensor, etc.
Cada ator representa um papel em relao ao sistema. Um ator pode participar

de muitos casos de uso e um caso de uso tambm pode envolver vrios atores: prim-
rios e secundrios. O ator primrio aquele que inicia uma seqncia de interaes
de um caso de uso; o secundrio aquele que supervisiona, opera, mantm ou auxilia
na utilizao do sistema.

A comunicao ou interao entre as funcionalidades do sistema casos de

uso e os usurios do sistema atores feita por meio dos relacionamentos. Os
tipos de relacionamentos disponveis para os diagramas de caso de uso so:
Comunicao mais comumente utilizado. Faz a troca de informaes entre
o ator e o caso de uso.
Incluso disponvel somente entre casos de uso. Utilizado quando dois ou
mais casos de uso incluem uma seqncia comum de interaes.
Extenso utilizado para modelar situaes em que diferentes seqncias
de interaes podem ser inseridas em um caso de uso. Cada uma dessas se-
qncias diferentes representa um comportamento opcional, que s ocorre sob
certas condies ou dependendo da escolha do ator.
Generalizao o mesmo conceito utilizado para as classes. Permite que
um caso de uso (ou um ator) herde caractersticas de um caso de uso (ou ator)
mais genrico.
A tabela 6 ilustra os elementos grficos utilizados em um diagrama de casos de

uso.
Tabela 6 Elementos grficos do diagrama de casos de uso

Nome Representao
Elemento grfico: retngulo que agrupa os ca-
sos de uso e os relacionamentos
Fronteira do Sistema
Elemento grfico: boneco palito
Ator
Elemento grfico: elipse

Caso de Uso

Elemento grfico: linha simples
Relacionamento de Comunicao
Elemento grfico: seta tracejada com estereti-

Relacionamento de Incluso somente entre ca- po: <<include>>
sos de uso
Elemento grfico: seta tracejada com estereti-

Relacionamento de Extenso somente entre po: <<extend>>
casos de uso
Elemento grfico: seta fechada
Relacionamento de Generalizao
A figura 25 ilustra um exemplo de diagrama de casos de uso.
Figura 25 Diagrama de Casos de Uso

2.4 Diagrama de seqncia
O diagrama de seqncia faz parte dos diagramas da UML classificados como

diagramas de interao. Os diagramas de interao representam como o sistema age
internamente comportamento dos objetos, troca de mensagens entre os objetos
para que um ator atinja seu objetivo na realizao de um caso de uso. A modelagem
de um sistema de software geralmente contm diversos diagramas de interao.
O diagrama de seqncia d nfase na ordem temporal das mensagens tro-
cadas entre os objetos do sistema de software. Sua funo ilustrar a seqncia do
envio das mensagens entre os objetos no decorrer do tempo.
Assim como os outros diagramas da UML, o diagrama de seqncia possui
um conjunto de elementos grficos. A figura 26 ilustra um exemplo de diagrama de
seqncia e os seus elementos grficos.
Figura 26 Exemplo de diagrama de seqncia
De acordo com a figura 26, podemos verificar que o diagrama de seqncia,

assim como os demais diagramas, compartilham elementos grficos. No caso do
diagrama de seqncia os elementos que podem ser compartilhados entre os demais
diagramas so: atores, objetos e classes.
Os elementos grficos que so especficos deste diagrama so:
Focos de controle representa o tempo em que o objeto realiza uma ao.
O topo do foco de controle coincide com o recebimento de uma mensagem e
a parte de baixo coincide com a finalizao de uma operao realizada pelo

objeto em questo;
Linha da vida representa a vida do objeto;
Mensagem a troca de informao entre os objetos. Por meio de uma
mensagem, um objeto faz a chamada da operao de outro objeto.
2.5 Diagrama de grfico de estados
Os diagramas de interao permitem modelar o funcionamento interno de um

sistema, detalhando a interao dos objetos troca de mensagens e a realizao
das operaes no decorrer do tempo. O diagrama de grfico de estados, por sua vez,
tem como objetivo demonstrar o funcionamento interno de apenas um objeto. Nesse
diagrama possvel ilustrar as aes que um objeto pode sofrer durante o seu perodo
de vida no sistema e quais os estados que ir assumir aps a realizao de cada uma
dessas aes.
Um estado pode ser interpretado como uma situao na vida de um objeto du-
rante a qual ele satisfaz alguma condio ou realiza alguma atividade. Cada estado
de um objeto normalmente determinado pelos valores dos seus atributos e/ou pelas
suas ligaes com outros objetos. Exemplos: (1) o atributo reservado deste objeto
livro tem valor verdadeiro; (2) uma conta bancria passa para o vermelho quando o
seu saldo atributo do objeto conta bancria 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 grficos do diagrama de estados esto ilustrados na tabela 7.
Tabela 7 Elementos grficos do diagrama de estados

Nome Representao
Elemento grfico: crculo preenchido
Estado inicial do objeto
Elemento grfico: crculo elipsado

Estado final do objeto
Elemento grfico: retngulo arredondado
Estado do objeto
Eventos / Aes um evento algo que aconte-

Elemento grfico: seta
ce em algum ponto do tempo e pode modificar o
estado do objeto. Uma ao uma operao que
pode ser realizada pelo prprio objeto.
2.6 Diagrama de atividades
Um diagrama de atividade essencialmente um grfixo de fluxo, que exibe o

fluxo de controle de uma atividade para outra. Ao contrrio de um grfico de fluxo
tradicional, um diagrama de atividades mostra a concorrncia, bem como as ramifica-
es de controle.
Os diagramas de atividade so utilizados para fazer a modelagem de aspectos
dinmicos do sistema que envolve a modelagem das etapas seqenciais 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 grficos do diagrama de estados esto ilustrados na tabela 8.
Tabela 8 Elementos grficos do diagrama de atividades

Nome Representao
Elemento grfico: crculo preenchido
Estado inicial da atividade
Elemento grfico: crculo elipsado

Estado final da atividade
Elemento grfico: raias de natao
Atores envolvidos na atividade
Elemento grfico: retngulo arredondado

Ao dos atores nas atividades

Elemento grfico: losango

Deciso
Transio das Aes Elemento grfico: seta
Sntese da Aula

1) A classificao 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 caractersticas, objetivos e representao de cada um destes diagra-
mas.
Exerccios Propostos
1) Complete a frase com uma das alternativas abaixo: As classes so 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 Seqncia
3) Assinale a alternativa incorreta. O ator um elemento que pode ser comparti-

lhado entre os seguintes diagramas:
a) Diagrama de Seqncia
b) Diagrama de Estados
c) Diagrama de Atividades
d) Diagrama de Casos de Uso
4) O relacionamento de comunicao um relacionamento exclusivo do diagra-

ma de:
a) Classes
b) Casos de Uso
c) Atividades
d) Seqncia

Aula 5
CONHECENDO O PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
Nesta quinta aula voc estudar os conceitos bsicos

sobre o processo de desenvolvimento de software;
analisar o que um processo de desenvolvimento de
software,quais as atividades desempenhadas no processo, quais
os padres existentes e, por fim, alguns dos principais modelos de
processos disponveis.
Bons Estudos!
Objetivos da Aula

Identificar os conceitos bsicos do processo de desenvol-
vimento de software;
Enumerar as atividades do processo;
Descrever os padres de processo existentes;
Analisar os modelos de processo disponveis.
Contedos da Aula

Introduo ao Processo de Desenvolvimento de Software;
Conhecendo os Modelos do Processo;
Exerccios Propostos.

1 INTRODUO AO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
Um Processo de desenvolvimento de software pode ser considerado como um con-

junto de atividades que tm como resultado final um produto de software.
Esse conceito um dos itens estudados pela Engenharia de Software e um

dos principais mecanismos que permite alcanar as caractersticas 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 rpido crescimento da demanda por software, da complexidade dos
problemas a serem resolvidos e da inexistncia de tcnicas estabelecidas para
o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem
ser validados.
As causas da crise do software esto ligadas complexidade do processo de
software e relativa imaturidade da engenharia de software como profisso. A crise
se manifesta de vrias formas:
Projetos estourando o oramento;
Projetos estourando o prazo;
Software de baixa qualidade;
Software muitas vezes no atingia os requisitos;
Projetos ingerenciveis e o cdigo difcil de manter;
A maior parte dos projetos continua com esses problemas ainda na atualidade,
ento 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. Anlise de requisitos de software a extrao dos requisitos de um dese-
jado produto de software a primeira tarefa na sua criao. Embora o cliente,
provavelmente, acredite saber o que o software deva fazer, essa tarefa requer
habilidade e experincia em engenharia de software para reconhecer os requi-
sitos em um sistema de software complexo.
2. Especificao a especificao 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
representao abstrata do sistema. Por meio das tarefas realizadas nessa ati-
vidade, ser possvel identificar se o sistema de software a ser desenvolvido
est de acordo com os requisitos pr-definidos. A etapa da arquitetura tambm
direciona as interfaces entre os sistemas de software e outros produtos de sof-
tware, como tambm com o hardware bsico ou com o sistema operacional.
4. Implementao (ou codificao) a atividade responsvel pelo desen-
volvimento do projeto do software efetivamente. nessa atividade que o sof-
tware comear a ser construdo e codificado por meio de linguagens de pro-
gramao e outras tecnologias pr-definidas nas atividades de Especificao
e Arquitetura de Software.
5. Teste atividade que desenvolve os testes das funcionalidades do software.
Os testes sero sempre baseados nos artefatos e modelos resultantes das ati-
vidade de Especificao e Arquitetura de Software. Caso uma funcionalidade
no esteja de acordo com sua definio, dever ser reescrita. Existem vrios
mtodos que auxiliam no controle do desenvolvimento e testes das funcionali-
dades.
6. Documentao atividade que se refere documentao do projeto inter-
no do software para propsitos de futuras manutenes e aprimoramentos. As
documentaes mais importantes so das interfaces externas. Grande parte

dessa documentao j foi gerada nas atividades anteriores, principalmente

nas atividades de Especificao e de Arquitetura de Software. A atividade de
Implementao tambm deve incorporar tarefas de documentao, principal-
mente para descrever e/ou detalhar as instrues que so 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 no perceber que no
importa quanto tempo a equipe de planejamento e desenvolvimento ir gastar
na criao do software se ningum da organizao ir us-lo. As pessoas,
ocasionalmente, resistem mudana e evitam aventurar-se em reas pouco
familiares. Ento, como parte da fase de desenvolvimento, muito importante
o treinamento para os usurios de software mais entusiasmados, alternando
o treinamento entre usurios neutros e usurios favorveis ao software. Os
usurios, freqentemente, tero muitas questes e problemas de software que
permitiro conduzir o desenvolvimento da prxima fase.
8. Manuteno a manuteno e melhoria de software lidam com a desco-
berta de novos problemas e requisitos. Pode tomar mais tempo que o gasto no
desenvolvimento inicial. No somente pode ser necessrio adicionar cdigos
que combinem com o projeto original, mas determinar como o software traba-
lhar em algum ponto depois da manuteno estar completa, pode requerer
um significativo esforo por parte de um engenheiro de software. Cerca de
de todos os engenheiros de software trabalham com a manuteno, mas essas
estatsticas podem estar enganadas, pois uma pequena parte desles trabalha
na correo de erros. A maioria das manutenes 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 interao entre elas.

Figura 29 Atividades do Processo de Desenvolvimento de Software
1.3 Padres do Processo
O processo de desenvolvimento de software tem sido objetivo de vrios pa-

dres, que visam certificao das empresas como possuidoras de um processo de
desenvolvimento. Em alguns casos, possuir uma certificao de padro de processo
de desenvolver pode gerar certo grau de confiana aos contratantes.
Alguns padres existentes atualmente so:
CMMI Capability Maturity Model Integration um modelo de referncia
que contm prticas necessrias maturidade em disciplinas especficas como:
Engenharia de Sistemas, Engenharia de Software, Integrao 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 evoluo 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 aquisio e configurao dos servios 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, tambm conhecida como SPICE, a norma ISO/

IEC que define um processo de desenvolvimento de software. uma evoluo

da ISO/IEC 12207 mas possui nveis 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 mdias 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 dcada 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 tcnicas 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 oramento.
De acordo com as pesquisas do Standish Group, vimos que o percentual de
projetos bem sucedidos ainda no suficiente. Isso indica que um grande nmero de
projetos de software no atende s expectativas em termos de funcionalidades, cus-
to, ou cronograma de entrega, portanto, acredita-se que ainda no existe um modelo
de processo perfeito para todas as aplicaes. Na aula 7 verificaremos as principais
tendncias 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 seqencial. A figura 30 ilustra o mto-

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 soluo, arquitetam um esboo do
software, implementam o cdigo, testam - inicialmente os testes unitrios e os testes
de sistema -, implantam e o mantm. Ao final de cada atividade, o processo segue
para a prxima atividade. Essa caracterstica considerada uma das desvantagens
do modelo, pois novos requisitos podem surgir na atividade de projeto ou ainda na
atividade de implementao, porm a anlise mais detalhada desses itens no feita
devido fase de especificao j ter sido desenvolvida.
Assim, se as iteraes no so includas no planejamento, o processo no tem
meios para corrigir os erros nas etapas inicias, ento o processo inteiro da engenharia
de software deve ser executado at o fim, resultando em funcionalidades de software
desnecessrias ou sem uso.
Esse modelo adequado nas seguintes situaes:
Existe um conjunto de Requisitos estveis e de alta qualidade segundo
especialistas, Requisitos sempre sofrem mudanas, sendo esta viso muito
idealista;
A durao do projeto pequena, menor que dois anos;
O sistema completo deve estar disponvel 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 mdulos -, porm 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 no sabe exatamente
o que quer, ou quando no se conhece bem todos os aspectos da soluo.
Os processos de desenvolvimento gil de software so construdos com os funda-
mentos do desenvolvimento iterativo. Os processos geis usam o feedback, mais que
o planejamento, como seus mecanismos de controle primrio. O feedback uma das
prticas que descreve o que foi produzido pelos testes regulares e das verses do
software desenvolvido.
Esse modelo adequado nas seguintes situaes:
A liberao do software deve estar de acordo com um conjunto de prioridades
definidas nos Requisitos;
necessrio melhorar a eficincia da integrao do software com outra par-
tes de um sistema maior;
Requerem-se, antecipadamente, evidncias 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 experincia acumulada dos seus
criadores.
O processo unificado, ou UP, como conhecido, o primeiro processo de
desenvolvimento a explorar integralmente as capacidades da linguagem UML. Alm
disso, baseia-se nas prticas 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 trs amigos, criadores da UML e do
Processo Unificado. A Rational foi comprada pela IBM no ano de 2003.
A frmula a seguir, define de maneira resumida o conceito do processo de sof-
tware unificado:
RUP = Processo + Mtodos + 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

Sntese da Aula

1) O processo de desenvolvimento de software e as suas principais caracters-
ticas;
2) As atividades do processo de desenvolvimento de software;
3) Os padres do processo de desenvolvimento de software;
4) Os principais modelos do processo de desenvolvimento de software.
Exerccios Propostos
1) Assinale a alternativa incorreta. As caractersticas responsveis pela crise de

software so:
a) Projetos estourando o oramento;
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 responsvel pela

entrevista com usurio e levantamento das informaes :
a) Anlise de requisitos de software;
b) Especificao;
c) Manuteno;
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) Anlise de requisitos de software;

b) Especificao;
c) Manuteno;
d) Suporte e Treinamento de Software.
4) O modelo de processo totalmente compatvel 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 anlise e projeto de
software. Estudar quais so as atividades dessa etapa, quais as
prticas 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 prticas utilizados para modelar
projetos de software;
Criar modelos utilizando a lingaugem UML.
Contedos da Aula

Anlise e Projeto de Software;

1 ANLISE E PROJETO DE SOFTWARE
A modelagem de software se d principalmente na etapa de anlise do projeto

de software, caracterstica em que aconselhvel desenvolver um modelo, analisar
os detalhes de funcionamento por meio do modelo, aperfeio-lo e, por fim, desenvol-
ver o produto final com base no modelo.
A etapa de anlise 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 tm o mau costume de pular
a etapa de anlise indo diretamente para a etapa de desenvolvimento essa atitude
por ser justificada pela inexperincia dos desenvolvedores ou ainda por falta de um
modelo de processo de desenvolvimento de software definido.
Projetos de software que ocasionalmente no passaram por todas as ativida-
des definidas no processo de desenvolvimento de software, freqentemente possuem
falhas na definio do software, ou seja, descobre-se, aps o desenvolvimento que
o que foi feito no atende necessidade existente. Dessa forma, imprescindvel
adotar e seguir um modelo para garantir o sucesso no desenvolvimento dos projetos
de software.
As principais atividades desenvolvidas na etapa de anlise so:
Levantamento de informaes;
Anlise dos requisitos;
Transformao dos requisitos em casos de uso e diagramas de casos de
uso;
Modelagem dos diagramas de classes, seqncia, atividades e estado a
modelagem de todos os diagramas vai depender da complexidade do projeto
de software;
Desenvolvimento de prottipos de telas atividade opcional.


1.2 Levantamento de Informaes
Nessa etapa, o analista realiza o levantamento de informaes com o usurio.

O analista pode utilizar vrias tcnicas como entrevistas com o usurio para descobrir
as necessidades existentes. As tcnicas mais utilizadas para levantamento de infor-
maes com os usurios so:
Entrevistas;
Observao in loco - observao do processo na casa do usurio;
Encontros/Reunies.
Essas trs tcnicas so complementares e podem todas ser usadas numa

mesma anlise de requisitos. A entrevista normalmente a primeira tcnica utilizada.
Os analistas entrevistam os usurios para definir os objetivos gerais e as restries
que o software dever ter. A entrevista deve ser feita de forma objetiva visando obter
o mximo de informaes do usurio.
Na observao in loco, os analistas devem estar inseridos na rotina de trabalho
da organizao tentando entender e descrever as principais atividades realizadas.
Devem ser identificadas quais so as atividades que podem ser automatizadas; quem
so os potenciais usurios; quais tarefas eles querem realizar com a ajuda do novo
sistema, etc. A observao deve ser complementada com entrevistas especficas com
os futuros usurios.
Os encontros so reunies envolvendo analistas, clientes e usurios e tm
como objetivo principal o levantamento de informaes, a descrio dos problemas
atuais e as metas futuras. aconselhvel que os encontros sejam realizados em um
local neutro - fora da organizao e que as informaes levantadas, sejam afixadas
em painis, na sala de encontro para que possam ser analisadas e validadas pelos
clientes e usurios. Ao final do encontro, os analistas devem elaborar um relatrio
descrevendo os requisitos analisados.
Independente da tcnica de levantamento utilizada, o analista deve estar sem-
pre atento s informaes fornecidas pelo usurio, pois cada detalhe mencionado por
usurio, muitas vezes pode resultar em mudanas no planejamento que o analista j
estava realizando.

Nem sempre o usurio tem todas as informaes que o analista necessita. Mui-
tas vezes, o usurio tem informao sobre o seu trabalho no momento, mas a diretoria
tem um planejamento futuro em relao ao trabalho que afeta a aplicao e no de
conhecimento do usurio. Assim o analista deve sempre consultar outras pessoas
alm dos usurios da aplicao.
A tabela 10 mostra um exemplo de questionrio que pode ser aplicado em uma entre-
vista com o usurio.
Tabela 10 Exemplo de Questionrio

1. Qual o objetivo do Sistema?
2. Que rea vai atender?
3. Que tipo e quantos usurios estaro interagindo com o sistema?
4. Quais so as principais funcionalidades que o sistema dever possuir?
5. Quais funcionalidades os usurios podero acessar?
6. necessrio utilizar perfil de usurio para definir acesso aos usurios?
7. Qual plataforma o sistema utilizar?
8. Qual o banco de dados que ir utilizar?
9. O sistema estar alocado dentro da empresa ou em um servidor de terceiro?
10. Qual o prazo de entrega?
11. Necessita de uma equipe para o treinamento do Projeto?
12. H disponibilidade de algum para acompanhar o desenvolvimento?
13. Necessita treinamento no processo a ser sistematizado?
14. Necessidade de alguma linguagem especfica?
15. J h informaes em arquivos ou banco de outros sistemas?
16. Sistema ter integrao com outros sistemas atuais?
17. H uma limitao de oramento?
18. Qual a configurao padro das mquinas da empresa(Windows 95,98,2000, XP ou Linux)?
19. Haver manuteno mensal no sistema?
20. O sistema atender mais franquias da prpria empresa?
1.3 Levantamento de Informaes
Requisitos so objetivos ou restries estabelecidas por clientes e usurios do

sistema que definem as diversas propriedades do sistema. Um conjunto de requisitos
pode ser definido como uma condio ou capacidade necessria que o software deve
possuir para:
1. Que o usurio possa resolver um problema ou atingir um objetivo;
2. Ou atender s necessidades e/ou restries da organizao ou dos outros

componentes do sistema.
Tradicionalmente, os requisitos de software so separados em requisitos

funcionais e no-funcionais. Os requisitos funcionais so a descrio das diversas
funes que clientes e usurios querem ou precisam que o software oferea. Definem
a funcionalidade desejada do software. O termo funo usado no sentido genrico
de operao que pode ser realizado pelo sistema, seja atravs comandos dos usu-
rios ou pela ocorrncia de eventos internos ou externos ao sistema. Exemplos de
requisitos funcionais:
1. O software deve possibilitar o clculo dos gastos dirios, semanais, men-
sais e anuais com pessoal.
2. O software deve emitir relatrios de compras a cada quinze dias.
3. Os usurios devem poder obter o nmero de aprovaes, reprovaes e
trancamentos em todas as disciplinas por um determinado perodo de tempo.
A especificao de um requisito funcional deve determinar o que se espera

que o software faa, sem a preocupao de como ele faz. importante diferenciar a
atividade de especificar requisitos da atividade de especificao que ocorre durante o
desenvolvimento do software. Na especificao do software, deve-se tomar a deciso
de quais funes o sistema efetivamente ter para satisfazer o que os usurios que-
rem / necessitam.
Requisitos no-funcionais so as qualidades globais de um software, como
manutenibilidade, usabilidade, desempenho, custos e vrias outras. Normalmente,
esses requisitos so descritos de maneira informal e so difceis de validar. Exemplos
de requisitos no-funcionais:
1. A base de dados deve ser protegida para acesso apenas de usurios auto-
rizados.
2. O tempo de resposta do sistema no deve ultrapassar 30 segundos.
3. O software deve ser operacionalizado no sistema Linux.
4. O tempo de desenvolvimento no deve ultrapassar seis meses.
A necessidade de se estabelecer os requisitos de forma precisa crtica me-

dida que o tamanho e a complexidade do software aumentam. Os requisitos exercem

influncia 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 mveis pode implicar em que o requisito desempenho no seja
satisfeito.
O resultado final da anlise e especificao de requisitos e das outras ativida-
des da fase de defino deve ser apresentado aos clientes para que possam valid-lo.
Esse documento oferece a concordncia entre clientes, analistas e desenvolvedores
sobre o que deve ser desenvolvido. utilizando esse documento que as atividades da
fase de desenvolvimento codificao sero validadas.
Cada desenvolvedor utiliza um modelo especfico para elaborar este documen-
to. A sua estrutura, muitas vezes, depende do mtodo que est sendo utilizado. Em
linhas gerais, esse modelo deve ser basicamente textual, utilizando o mnimo de ter-
mos tcnicos, e ilustrados como modelos grficos que demonstrem mais claramente a
viso que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.
A tabela 11 ilustra uma lista de requisitos funcionais e no-funcionais de um sis-
tema de software. A lista de requisitos se refere s informaes levantadas para uma
faculdade que necessita de aplicao para controlar processos acadmicos como: vi-
sualizao de notas pelos alunos, cadastro de disciplinas, alocao de recursos para
as turmas, etc.
Tabela 11 Lista resumida de requisitos

# Descrio Tipo
O sistema deve permitir aos alunos visualizar as notas das
1 Requisito Funcional
disciplinas por semestre letivo.
O sistema deve permitir o lanamento das notas dos alu-
nos por disciplina pelos professores.
O sistema deve permitir a abertura de turmas para uma
disciplina, com a definio de sala e laboratrios a serem
utilizados e dos horrios e dias da semana em que haver
aulas.
4 O sistema deve ser desenvolvido para a plataforma WEB Requisito No-Funcional

1.4 Transformao dos requisitos em casos de uso e diagramas de casos de

uso
Aps a definio dos requisitos do sistema de software, possvel dar incio

identificao dos atores e casos de uso para a elaborao do diagrama de casos
de uso. Os atores devem ser encarados como os agentes externos ao sistema, por
exemplo: usurios, outros sistemas, computadores externos, impressoras etc. J os
casos de uso sero as funcionalidades do sistema ou os requisitos funcionais do sis-
tema.
Para auxiliar na identificao dos atores do sistema, podem ser utilizadas as
seguintes questes:
1. Quem ir utilizar as funes principais do sistema?
2. Quem precisar do sistema para realizar as suas tarefas dirias?
3. Quem ir manter, administrar e deixar o sistema funcionando?
4. Existe interao com outros sistemas? Quais?
5. Quem ou o que est interessado nos resultados (valores) que o sistema
produz?
Com base na lista de requisitos, disponvel na tabela 11, e as questes acima

citadas, identificaram-se os seguintes atores:
Aluno;
Professor;
Secretaria.
Para auxiliar na identificao dos casos de uso, podem ser utilizadas as se-
guintes questes:
1. Quais funes 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 dirias simplificadas ou feitas de modo
eficiente se alguma nova funo for adicionada?
Com base na lista de requisitos, disponvel na tabela 11, e as questes acima

citadas, identificaram-se os seguintes casos de uso:
Visualiza Notas;
Lana Notas;
Cadastra Disciplina;
Abre Turmas;
Define Horrio das Turmas.

Aps a identificao dos atores e casos de uso, possvel modelar o diagrama
de casos de uso e, caso seja necessrio, 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 contrrio, um detalhamento
maior no necessrio. 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 identificao 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 vrios dia-
gramas podendo ser vrias verses de um mesmo diagrama dessa forma,
sempre coloque um nome para os diagramas identificando a situao ou fun-
cionalidade que o diagrama representa. Isso facilitar a tarefa de modelagem
de software.
3. Para criar um novo diagrama, basta clicar na opo: Diagram na barra de
ferramentas e selecionar o diagrama desejado. Como a ferramenta est dis-
ponvel apenas no idioma ingls, segue abaixo a traduo para os principais
diagramas UML:
a) Diagrama de Caso de Uso = UseCase Diagram

b) Diagrama de Classes = Class Diagram

c) Diagrama de Seqncia = Sequence Diagram
d) Diagrama de Estado = StateChart Diagram
e) Diagrama de Atividade = Activity Diagram
4. Modele o diagrama utilizando os elementos grficos disponveis. Se ne-

cessrio, volte aula 4, onde so abordados todos os elementos grficos dos
diagramas.
1.5 Modelagem dos diagramas de classes, seqncia, atividades e estado
Aps a definio do diagrama de casos de uso e a sucessiva validao pelo

cliente - usurio final -, possvel dar continuidade no processo de modelagem do
projeto de software. No h uma seqncia lgica para a elaborao dos demais
diagramas e tambm no h uma quantidade especfica 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 mximo 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 sero criados. Os demais diagramas, como j informado,
podero ser modelados de acordo com a complexidade do sistema e/ou funcionalida-
des que esto sendo modeladas.
Para auxiliar na identificao das classes do sistema, podem ser utilizadas as
seguintes questes:
1. Existem informaes que devem ser registradas ou analisadas?
2. Existe interao com sistemas externos?
3. Existem padres, bibliotecas, pacotes, componentes, etc a serem utiliza-
dos?
4. Existem informaes que devem ser manipuladas de qualquer forma? Quais?
(Detalhar atributos e operaes)
5. Existem representaes organizacionais?

6. Quais papis representam os atores no negcio?

7. Existem dispositivos que sero manipulados pelo sistema?
Com base na lista de requisitos da tabela 11 e definio dos casos de uso do

sistema funcionalidades do sistema (figura 33) foram identificadas as seguintes
classes para o projeto de software:
Classes que iro manter os dados dos atores:
Aluno;
Professor;
Secretaria.
Classes que iro manter os dados das informaes do sistema:

Semestre;
Disciplina;
Turma;
Horrio;
Sala;
Laboratrio;
Nota.
Veja na figura 34 o diagrama de classes sugerido para o sistema.

Figura 34 Diagrama de Classes do Sistema
O diagrama de seqncia ir representar o funcionamento interno do sistema,

em relao a uma ou mais funcionalidades. Pode-se utilizar como referncia a defini-
o e o detalhamento dos casos de uso identificados para o sistema. No diagrama de
seqncia ser ilustrada a ao de um ator e a troca de mensagens entre os objetos
do sistema, a fim de realizar a operao iniciada pela ao do ator.
Veja na figura 35 o diagrama de seqncia modelado para descrever o funcio-
namento interno do caso de uso: Visualiza Nota.

Figura 35 Diagrama de Seqncia do Caso de Uso: Visualiza Nota
O diagrama de estado ir ilustrar o funcionamento interno de um objeto do

sistema. Nesse diagrama sero ilustrados os estados que um objeto poder assumir,
dependendo da operao realizada pelo ator ou pelo prprio objeto. Esse diagrama
deve ser utilizado somente para os objetos que possuem uma complexidade conside-
rvel e necessitam de detalhamento para melhor anlise.
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, alm da interao dessa funcionalidade com os atores do sistema. Esse

diagrama tambm poder ser modelado com base na definio 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 prottipos de telas
Essa atividade uma tarefa opcional, pois sua finalidade demonstrar de for-
ma visvel o layout das telas do sistema a ser desenvolvido. muito til para sistemas
extremamente complexos e com grande quantidade de telas, porm, mesmo nesse
caso, aconselhvel desenvolver os prottipos das telas mais complexas, para evitar

desperdcio de tempo em atividades que no iro agregar qualidade ou produtividade

ao produto final.
Ferramentas CASE como o VISIO da Microsoft permitem o desenvolvimento de
prottipos com grande qualidade e proximidade do layout das telas do sistema real.
Veja na figura 38 um exemplo de prottipo de tela desenvolvido com o VISIO.
Figura 38 Prottipo de Tela
Sntese da Aula

1) As principais atividades desenvolvidas na etapa de anlise e projeto de sof-
tware;
2) As melhores prticas para o desenvolvimento das atividades;
3) Como modelar os principais diagramas UML;
4) Exemplos de mtodos e tcnicas que podem ser aplicadas durante a mode-
lagem de projetos de software.

Exerccios Propostos
1) Analise os requisitos abaixo e desenvolva as seguintes atividades:

a) Identificao dos Atores do Sistema;
b) Identificao dos Casos de Uso do Sistema;
c) Elaborao do Diagrama de Casos de Uso;
d) Identificao das Classes do Sistema;
e) Elaborao do Diagrama de Classes.
# Descrio Tipo
O sistema deve permitir ao Funcionrio ca-
1 dastrar Clientes contendo os dados: nome, Requisito Funcional
endereo, e telefone
dastrar Cidades que representam os lugares
2 abrangidos pela empresa de transportes e Requisito Funcional
contm o nome da cidade, o estado a que
pertence e o valor para a taxa de entrega
dastrar Fretes contendo um cdigo, uma des-
crio, o peso total, um cliente e a cidade de
destino, no 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
4 O sistema deve ser para plataforma WEB Requisito No-Funcional

Aula 7
TENDNCIAS DO PROCESSO DE
ENGENHARIA DE SOFTWARE
Nesta aula voc estudar sobre as principais tendncias

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 tendncias para o desenvolvimento
e gerenciamento de projetos de software.
Contedos da Aula

A importncia do Software;
Metodologias geis;

1 A IMPORTNCIA 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 dcada
de 1990. um mecanismo para automatizar os negcios, a indstria e o governo, um
meio de transferir novas tecnologias, um modo de captar valiosa experincia 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 atuao da sociedade. Atualmente, muito difcil irmos
a um lugar ou qualquer estabelecimento que no possua um software ou sistema de
informao que permita gerenciar, automatizar ou suportar algumas das atividades.
possvel tambm, verificar a evoluo dos softwares que vm sendo desen-
volvidos atualmente. A disseminao e busca pela melhoria no desenvolvimento de
software tambm aumentou aps a popularizao dos meios de comunicao 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-
nvel na Internet. Tambm bastante comum que empresas de segmentos diversos
tenham o seu carto de visitas disponvel em forma de um site na Internet.
E a evoluo no pra por a. O software tem atingido ambientes diversos
tambm, fora do mundo dos computadores e sua rede mundial. Tendncias como:
softwares embarcados sistema especfico que faz parte de um minicomputador,
mquina ou sistema mais amplo -, tecnologias mveis sistema desenvolvido para
aparelhos de celulares e outros dispositivos mveis e sistemas para televiso digital
tm proporcionado uma grande evoluo na rea da engenharia de software, que vem
expandindo com grande velocidade a sua rea de atuao.
Conforme a rea de atuao da engenharia de software foi aumentando, mu-
danas no processo de desenvolvimento e nas tcnicas utilizadas comearam a sur-
gir. O objetivo dessas mudanas 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 mudanas que afetaro a engenha-
ria de software ao longo das prximas dcadas sero influenciadas a partir de quatro
direes simultneas: (1) as pessoas que fazem o trabalho; (2) o processo que elas
aplicam; (3) a natureza da informao; (4) e a tecnologia de computao subjcente.
1.2 Software baseada em Componentes
Engenharia de Software Baseada em componentes um ramo de Engenharia

de Software, com nfase na decomposio dos sistemas em componentes funcionais
e lgicos com interfaces bem definidas, usadas para comunicao entre os prprios
componentes.
Componentes esto em um nvel de abstrao mais alto que do que Objetos,
porm comunicam-se por troca de mensagens contendo dados. Os componentes
possuem uma interface e tambm empregam regras de herana. So definidos para
oferecer certo nvel de servio. No caso dos componentes comerciais de prateleira,
o engenheiro de software sabe pouco ou nada sobre o seu funcionamento interno.
Ao invs disso, ao engenheiro de software dada apenas uma interface externa bem
definida a partir da qual ele deve trabalhar.
Ao contrrio de objetos em OO, os componentes so usualmente construdos 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
especfica em um dado nvel de servio.
A grande vantagem de se trabalhar com componentes a possibilidade de
reutilizao, por meio da qual tanto a produtividade quanto a qualidade seriam bene-
ficiadas, pois um componente deve possuir exatido na funo que desempenha.
1.3 Padres de Projetos
Os padres de projeto, tambm muito conhecido pelo termo original em ingls:

Design Patterns, descrevem solues para problemas recorrentes no desenvolvimen-
to de sistemas de software orientados a objetos. Um padro de projeto estabelece um

nome e define o problema, a soluo, quando aplicar essa soluo e suas conseq-
ncias.
Os padres de projeto visam facilitar a reutilizao de solues de desenho -
isto , solues na fase de projeto do software, sem considerar reutilizao de cdigo.
Tambm acarretam um vocabulrio comum de desenho, facilitando comunicao, do-
cumentao e aprendizado dos sistemas de software.
O movimento ao redor de padres de projeto ganhou popularidade com o li-
vro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em
1995. Os autores desse livro so Erich Gamma, Richard Helm, Ralph Johnson e John
Vlissides, conhecidos como a Gangue dos Quatro (Gang of Four) ou simplesmente
GoF. Posteriormente, vrios 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 padres 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 evoluo de mtodos, tc-
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 rgo Standish Group, que apenas 34% dos projetos de
software so 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. Documentaes extensivas e artefatos que muitas ve-
zes so desenvolvidos no incio do projeto e depois engavetados durante o processo
de desenvolvimento, so apontadas como as principais causas de no sucesso dos
projetos.
Com o avano sucessivo da tecnologia e o aumento da velocidade de sua
propagao, surge cada vez mais a necessidade de desenvolver software de forma
mais rpida, porm sempre privando pela qualidade. Esse aumento na capacidade

da produtividade de desenvolvimento dos softwares pode ser conseguido por meio da

aplicao de mtodos geis e padres 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 prprias prticas e teorias sobre como fazer um projeto de
software ter sucesso, todos concordavam que, em suas experincias prvias, um pe-
queno conjunto de princpios 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 -, freqentemente chamado apenas de Manifesto gil.
Os princpios propostos pelo Manifesto gil segundo Beck ( 2001), so:
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns

mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valori-
zar:
Indivduos e interaes so mais importantes que processos e ferramen-
tas;
Software funcionando mais importante do que documentao detalhada;
Colaborao dos clientes mais importante do que negociao de contra-
tos;
Adaptao s mudanas mais importante do que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens es-
querda.
O Manifesto gil no rejeita os processos e ferramentas, a documentao,

a negociao de contratos ou o planejamento, mas simplesmente mostra que eles
tm importncia secundria quando comparado com os indivduos e interaes, com
o software estar executvel, com a colaborao do cliente e as respostas rpidas a
mudanas e alteraes. Esses conceitos aproximam-se melhor com a forma que pe-
quenas e mdias organizaes trabalham e respondem a mudanas.
Assim, foi a partir do Manifesto gil que ocorreu a popularizao dos mtodos
geis que passaram a ser usados em empresas, universidades, institutos de pesqui-
sa e at em agncias governamentais. Algumas das metodologias geis existentes

so:
XP (eXtreme Programming);
DSDM (Dynamic Systems Development Method);
Famlia Crystal;
ASD (Adaptive Software Development);
SCRUM;
FDD (Feature-driven development);
LD (Lean Development);
Open Source.
Com exceo dos autores das metodologias: LD e OpenSource, os demais

autores das metodologias citadas participaram da criao do Manifesto gil, portanto,
possuem princpios em comum.
Sntese

1) A importncia do software;
2) Conceitos bsicos sobre Engenharia de Software Baseada em Componen-
tes;
3) Conceitos bsicos sobre Padres de Projeto;
4) Conceitos bsicos sobre Metodologias geis.

Exerccios propostos
1) Assinale a alternativa incorreta. De acordo com PRESSMAN, as mudanas

que podem afetar a Engenharia de Software so:
a) Pessoas que desenvolvem;
b) Processo de desenvolvimento;
c) Natureza da Informao;
d) Certificao de Padro.
2) Os componentes:
a) Possuem vrias funcionalidades;
b) Possuem uma interface bem definida;
c) Implementam Herana;
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 nvel de documentaes;
c) Incluir o cliente em todo o processo de desenvolvimento;
d) Adaptao s mudanas.

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.
Contedos da Aula

Definio do Estudo de Caso e elaborao dos modelos
de software.

1 DEFINIO DO ESTUDO DE CASO
Nesta aula, apresentaremos uma descrio 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 gesto de festas
de casamento. O software dever permitir ao usurio, dentre outras coisas, escolher
o buffet, se haver grupo musical, escolher tipo de decorao, entre outros itens. O
usurio tambm poder definir uma loja para disponibilizao da lista de presentes. O
sistema dever emitir relatrio das vendas realizadas por perodo e gerar oramento.
Com base na definio do estudo de caso, vamos iniciar a atividade de anlise e
projeto de software e, por conseguinte a tarefa de identificao dos requisitos do sof-
tware.
1.2 Identificao dos Requisitos
Para auxiliar na tarefa de identificao dos requisitos de software, vamos revi-

sar as possveis definies para requisitos:
Caracterstica do sistema ou a descrio de algo que o sistema seja capaz de
realizar para atingir seus objetos;
As descries de funes e restries do sistema;
Propriedade que o software deve exibir para resolver algum problema no
mundo real;
Condio ou capacidade que deve ser alcanada ou estar presente em um
sistema para satisfazer um contrato, padro, especificao ou outro documen-
to formalmente imposto.
Enfim, podemos traduzir a definio de requisitos como um conjunto de ne-

cessidades explicitadas pelo cliente que devero ser atendidas para solucionar um
determinado problema de negcio do qual o cliente faz parte.
Os requisitos so classificados em dois tipos:

Funcionais diretamente ligados funcionalidade do software, descrevem

as funes que o software deve executar;
No-Funcionais expressam condies que o software deve atender ou
qualidades especficas 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

# Descrio Tipo
O sistema deve permitir que o gerente cadastre sales
de festas
O sistema deve permitir que o gerente cadastre pro-
fissionais
O sistema deve permitir que o gerente realize o cadas-
3 tro de servios utilizados em uma festa de casamento, Requisito Funcional
como buffet e carros utilizados
O sistema dever permitir que o cliente realize o ca-
dastro da lista de convidados
O sistema dever permitir que o cliente elabore a con-
figurao da festa
O sistema dever permitir a gerao do oramento
para o cliente
O sistema dever permitir que o gerente realize a im-
presso de relatrio de festas
O sistema dever permitir que o cliente cadastre a lista
de presentes
O sistema dever permitir que o gerente realize o ca-
dastro de usurios
O sistema dever permitir a autenticao dos usu-
rios
O sistema deve ser compatvel com os navegadores
11 Requisito No-Funcional
Internet Explorer e Firefox
O sistema deve garantir que o tempo de retorno das consul-
12 Requisito No-Funcional
tas seja inferior a 5 segundos

1.2 Identificao dos Atores e Casos de Uso
Aps a identificao dos requisitos de software e sua classificao em fun-

cionais e no-funcionais, podemos dar incio s tarefas de identificao dos atores e
casos de uso do sistema.
Apenas para relembrarmos, os atores so os agentes externos ao sistema,
porm possuem acesso s funcionalidades disponveis no sistema. Essas funcionali-
dades so os prprios casos de uso.
Com base na definio inicial do sistema proposto pelo estudo de caso e a
identificao e definio dos requisitos de software, encontramos os seguintes atores
e casos de uso:
Atores: Gerente, Cliente;
Casos de Uso:
Cadastra Salo de Festa;
Cadastra Servio;
Cadastra Profissional;
Configura Festa;
Gera Relatrio;
Cadastra Usurio;
Autentica Usurio.
Vimos que, dependendo da complexidade da funcionalidade caso de uso

possvel tambm 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 Usurio. Esse detalhamento permite uma
anlise mais criteriosa a respeito do funcionamento do caso de uso e suas principais
caractersticas.
Veja na tabela 13 o detalhamento elaborado para o caso de uso: Autentica Usu-
rio.

Tabela 13 Especificao do Caso de Uso: Autentica Usurio

Caso de Uso: Autentica Usurio
Efetuar o login dos usurios no sistema de acordo com o perfil de cada
Sumrio:
um e exibir as telas permitidas para cada perfil.
Ator Primrio: Gerente
Ator Secundrio: Cliente
Pr-Condio: Usurio acessa o sistema
1. O sistema apresenta formulrio contendo as informaes: Login e
Senha, alm das opes: Entrar e Cancelar.
2. Usurio informe os dados e seleciona a opo: Entrar [A1].
3. O sistema verifica a autenticidade dos dados informados pelo usu-
Fluxo Principal:
rio [A2].
4. O sistema autentica o usurio e apresenta a tela com as opes que
ele pode acessar.
5. Caso de uso encerrado.
A1. Usurio seleciona a opo: Cancelar
a. Caso de Uso encerrado
A2. Login ou senha invlida
Fluxo Alternativo: a. O sistema apresenta a mensagem: Usurio ou senha invlido
e a opo: OK.
b. O usurio seleciona a opo OK.
c. O caso de uso retorna para o passo 2 do fluxo principal.
1.4 Elaborando Diagrama de Casos de Uso
Aps a identificao dos atores e os casos de uso, possvel elaborar o dia-

grama de casos de uso que ir ilustrar a relao 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 identificao dos atores e casos de uso e da elaborao do diagra-

ma de casos de uso, possvel iniciar a tarefa de identificao das classes do sistema
do estudo de caso proposto.
Para identificar as classes, deve-se utilizar o conhecimento sobre o domnio do
problema negcio que est sendo modelado e a especificao de requisistos de
software elaborada. Deve-se procurar na especificao 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:
Salo;
Profissional;
Servio;
Festa;
Loja;
Presente;
Lista de Presente;
Lista de Convidado;
Convidado;
Usurio.
1.6 Elaborando o Diagrama de Classes
Aps a identificao das classes do sistema, podemos iniciar a elaborao do

diagrama de classes. Nessa etapa, devem ser realizadas as seguintes tarefas:
1. Identificao dos atributos das classes atributos so as propriedades que
caracterizam o objeto;
2. Identificao das operaes das classes operaes definem as aes que
um objeto pode realizar;
3. Identificao dos relacionamentos entre as classes;
4. Reviso 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 Seqncia, Estados e Atividades
Como vimos na aula 6 Modelando Projetos de Software a elaborao dos

diagramas de seqncia, 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 seqncia de uma das funcionalidades
do sistema. Os demais diagramas ficam como sugesto de lio de casa para voc
treinar as habilidades e conhecimentos adquiridos na disciplina.
O diagrama de seqncia que elaboraremos, representa o funcionamento in-

terno do caso de uso: Autentica Usurio. A elaborao do diagrama de seqncia ser

sempre feito com base na especificao dos requisitos de software, definio do caso
de uso e modelo de classes elaborado diagrama de classes.
A figura 41 ilustra o diagrama de seqncia proposto.
Figura 41 Diagrama de Seqncia do Estudo de Caso Proposto

CONCLUSO
Possuir um software que auxilie em tarefas diversas tornou-se algo muito co-
mum nos dias de hoje. Porm, mesmo com a grande evoluo que o software vem
sofrendo nas ltimas dcadas e da quantidade e diversidade de tecnologias que sur-
giram; desenvolver software ainda considerado uma atividade complexa.
A questo 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 compreenso do problema
de negcio a ser solucionado pelo software, portanto, so etapas que requerem um
alto grau de experincia por parte dos desenvolvedores e grande ateno, a fim
de identificar todos os requisitos e as possveis variaes decorrentes do processo de
desenvolvimento de software.
Portanto, imprescindvel aos profissionais de informtica, em especial que-
les que desejam trabalhar com desenvolvimento de software, possuir o conhecimento
dos principais assuntos relacionados ao tema e tambm das prticas 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 mdulo teve como objetivo principal fazer uma introduo aos co-
nhecimentos bsicos sobre os principais elementos dos projetos de software e s
melhores prticas para o processo de desenvolvimento.

REFERNCIAS
BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponvel em:
http://www.agilemanifesto.org.
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. Rio de

Janeiro: Elsevier, 2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio. Rio
de Janeiro: Elsevier, 2005.
Dicionrio Aurlio Online. Disponvel em: http://200.225.157.123/dicaureliopos/
PRESSMAN, Roger S. Engenharia de Software. So Paulo: Pearson Makron Books,

1995.
WIKIPDIA, a enciclopdia livre. Artigos Eletrnicos. Disponvel em: http://

pt.wikipedia.org/

APNDICE 1
1 O PARADIGMA DA ORIENTAO A OBJETOS
Um paradigma a forma de abordar um problema. Alan Kay, um dos pais do

paradigma da orientao a objetos, imaginou o funcionamento do sistema de software
como o de um ser vivo. Nesse sistema, cada clula interagiria com outras clulas
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 princpios da orientao a objetos:
Qualquer coisa um objeto;
Objetos realizam tarefas por meio da requisio de servios a outros objetos;
Cada objeto pertence a uma determinada classe;
Uma classe agrupa objetos similares;
A classe um repositrio para comportamento associado ao objeto;
Classes so organizadas em hierarquias.
Exemplo da utilizao dos princpios da OO:

1. Para comprar uma pizza VOC que est muito ocupado, pede sua pizza por tele-
fone;
2. VOC informa ao ATENDENTE seus dados e as caractersticas da pizza que de-
seja comprar;
3. O ATENDENTE atende sua solicitao e comunica ao PIZZAIOLO seu pedido;
4. O PIZZAIOLO faz a pizza e chama o ENTREGADOR;
5. O 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 alcanar o objetivo comum: entregar a pizza quentinha
na sua casa!
O paradigma da OO visualiza um sistema de software como uma coleo de
agentes interconectados (objetos). Cada objeto responsvel por realizar tarefas

especficas e por meio da interao entre os objetos que uma tarefa computacional
realizada.
Utilizar a OO para modelagem de sistemas diminui a diferena semntica entre
a realidade sendo modelada e os modelos construdos. A figura 42 ilustra a interao
entre os objetos.
Figura 42 Interao entre os objetos
1.1 O princpio da abstrao
Uma abstrao qualquer modelo que inclui os aspectos mais importantes e

essenciais de alguma coisa. As abstraes permitem gerenciar a complexidade e
concentrar a ateno nas caractersticas essenciais de um objeto.
Uma abstrao dependente da perspectiva: o que importante em um con-
texto pode no ser importante em outro.
As principais caractersticas da abstrao so:
Permite concentrar nos aspectos essenciais de uma aplicao;
Foca no que um objeto faz, antes de definir como implement-lo.
Veja na figura 43 os conceitos que envolvem a abstrao da OO.

Figura 43 Princpios da OO
1.1.1 Encapsulamento
As principais caractersticas do encapsulamento so:

Forma de restringir o acesso ao comportamento interno de um objeto;
Ocultamento de informaes;
Separa os aspectos externos de um objeto, que so acessveis a outros ob-
jetos, dos detalhes internos da implementao, escondidos de outros objetos.
1.1.2 Polimorfismo
O polimorfismo a capacidade de abstrair vrias implementaes diferentes

em uma nica interface. Exemplo: o controle remoto da televiso tambm funciona
com o aparelho de DVD.
O polimorfismo garante que objetos semelhantes possuam interfaces diferen-
tes.
1.1.3 Herana
As principais caractersticas da Herana so:

Classes semelhantes so agrupadas em hierarquias;
Cada nvel da hierarquia pode ser visto como um nvel de abstrao;
Cada classe em um nvel da hierarquia herda as caractersticas das classes nos
nveis acima.
A figura 44 ilustra um exemplo de herana.

Figura 44 Exemplo de Herana
1.1.5 Objetos
Os objetos esto em toda parte no mundo real:

Pessoas, Animais, Plantas, Carros, Avies, Edifcios, Computadores, etc;
Todos os objetos tm 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. possvel fazer comparaes, por exemplo, entre bebs e
adultos, e entre humanos e animais.
As principais caractersticas dos objetos so:
Objeto uma entidade, uma coisa que possui um estado e um comportamento;
O estado de um objeto caracterizado pelas suas variveis (atributos);
O comportamento, pelas suas funes (mtodos);
Cada objeto nico em seu escopo.
1.1.6 Estado dos Objetos
O estado de um objeto definido pelas suas caractersticas internas, como

peso, altura e profisso para uma pessoa. Em uma linguagem de programao, es-
sas caractersticas so implementadas atravs de variveis.

Na nomenclatura de OO, as variveis de um objeto so 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 so implementadas atravs
de funes. As funes so chamadas de mtodos em OO.
1.1.8 Objetos e Classes
Objetos afins so reunidos em categorias que descrevem suas caractersticas

comuns. Em OO, essas categorias so chamadas de classes. As classes so apenas
descries de estados e comportamentos (abstrao) e o objeto criado por meio de
uma classe.
Exemplo: Planta da Casa uma classe, a casa construda o objeto.

Copyright Tupy Virtual 2007

Nenhuma parte desta publicao pode ser reproduzida por qualquer meio sem a prvia autorizao desta instituio.
Autores: Rosemary Francisco
Elementos de Projetos de Informtica: Material didtico / Rosemary Francisco
Design institucional: Thiago Vedoi de Lima; Cristiane de Oliveira - Joinville: Tupy Virtual, 2007
Ficha catalogrfica elaborada pela Biblioteca Universitria Tupy Virtual
Crditos
SOCIESC Sociedade Educacional de Santa Catarina Design Grfico
Thiago Vedoi de Lima
Tupy Virtual Ensino a Distncia
Professor Responsvel
Rua Albano Schmidt, 3333 Joinville SC 89206-001 Rosemary Francisco
Fone: (47)3461-0166
E-mail: ead@sociesc.org.br
Site: www.sociesc.org.br/portalead EDIO MATERIAL DIDTICO
Diretor Geral Professor Conteudista

Sandro Murilo Santos Rosemary Francisco
Diretor de Administrao Design Institucional

Vicente Otvio Martins de Resende Thiago Vedoi de Lima
Cristiane Oliveira
Diretor de Ensino, Pesquisa e Extenso
Roque Antonio Mattei Ilustrao Capa
Diretor do Instituto Superior Tupy
Wesley Masterson Belo de Abreu Projeto Grfico
Equipe Tupy Virtual
Diretor da Escola Tcnica Tupy
Luiz Fernando Bublitz Reviso Ortogrfica
Ndia Ftima de Oliveira
Coordenador da Escola Tcnica Tupy
Alexssandro Fossile
Alan Marcos Blenke
Coordenador do Curso
Juliano Prim
Coordenador de Projetos
Jos Luiz Schmitt
Revisora Pedaggica
Ndia Ftima de Oliveira
EQUIPE TUPY VIRTUAL
Raimundo Nonato Gonalves Robert

Wilson Jos Mafra
Cristiane Oliveira
Janae Gonalves Martins

Apostila Elementos de Projeto de Informática PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Elementos de Projeto de Informática PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ELEMENTOS DE PROJETOS DE INFORMTICA

Apoio Gesto e Execuo Contedo e Tecnologia

Este livro didtico contm a disciplina de Elementos de Projetos de Inform-

SOCIESC - Sociedade Educacional de Santa Catarina

SOCIESC - Sociedade Educacional de Santa Catarina

Nos prximos captulos, ter incio a caminhada rumo ao conhecimento dos

SOCIESC - Sociedade Educacional de Santa Catarina

Portanto, muito importante que o profissional de informtica conhea as

Professora Rosemary Francisco

SOCIESC - Sociedade Educacional de Santa Catarina

Acompanhe no cronograma abaixo os contedos das aulas, e atualize as pos-

Semana Carga horria Aula Data/ Avaliao

SOCIESC - Sociedade Educacional de Santa Catarina

Introduo a projetos de desenvolvimento de software; Viso geral da linguagem

Carga Horria: 60 horas/aula.

SOCIESC - Sociedade Educacional de Santa Catarina

Nesta aula voc estudar os conceitos bsicos de pro-

Ao final desta aula voc dever ser capaz de:

SOCIESC - Sociedade Educacional de Santa Catarina

1 O QUE PROJETO DE INFORMTICA

Antes de compreendermos o que um projeto de informtica, importante sa-

Analisando os significados indicados pelo Dicionrio Aurlio, podemos ento

SOCIESC - Sociedade Educacional de Santa Catarina

1.2 PRINCIPAIS CARACTERSTICAS DE UM PROJETO

As principais caractersticas de um projeto so:

A caracterstica Planejamento, alm de estar diretamente relacionada com Du-

SOCIESC - Sociedade Educacional de Santa Catarina

Atualmente, existem vrios modelos que permitem auxiliar nas ta-

1.3 RESULTADO DOS PROJETOS DE SOFTWARE

Desde 1994, o Standish Group - www.standishgroup.com - publica um estudo

Veja na figura 1 o resultado do Chaos Research publicado at o ano de 2002.

SOCIESC - Sociedade Educacional de Santa Catarina

Figura 1 Resultado do Chaos Research at o ano de 2002

Analisando a figura 1, podemos observar que a quantidade de projetos consi-

2 O QUE ENGENHARIA DE SOFTWARE

A engenharia de software um rebento da engenharia de sistemas e de hardware.

SOCIESC - Sociedade Educacional de Santa Catarina

software e oferece ao profissional uma base para a construo de software de alta

O engenheiro John Presper Eckert e o fsico John Mauchly proje-

Antes do ENIAC, j havia alguns recursos e Ferramentas

SOCIESC - Sociedade Educacional de Santa Catarina

o possvel verificar na figura 2.

Figura 2 Evoluo do Software

De acordo com as caractersticas da primeira era da evoluo do software,

SOCIESC - Sociedade Educacional de Santa Catarina

Comearam a surgir as software houses, empresas dedicadas exclusiva-

Nessa poca tambm comearam a surgir as empresas dedicadas exclusiva-

SOCIESC - Sociedade Educacional de Santa Catarina

crescente demanda de acesso instantneo a dados exigem muito dos desen-

Para suprir as necessidades de mercado, nessa poca, novos conceitos como

SOCIESC - Sociedade Educacional de Santa Catarina

De acordo com as caractersticas da quarta era da evoluo do software, pode-

Assim, ao analisar a evoluo no desenvolvimento de software, fica mais fcil

SOCIESC - Sociedade Educacional de Santa Catarina

Portanto, a Engenharia de Software nasceu justamente para

Nesta aula estudamos:

2) Selecione a alternativa correta. A caracterstica de projeto que est diretamen-

SOCIESC - Sociedade Educacional de Santa Catarina

2) Selecione a alternativa correta. objetivo da Engenharia de Software:

3) Qual das alternativas abaixo uma caracterstica especfica da era atual de

SOCIESC - Sociedade Educacional de Santa Catarina

Nesta segunda aula voc estudar o que modelagem

Ao final desta aula, voc dever ser capaz de: