Apostilaelementosdeprojetodeinformtica 140716194941 Phpapp01 PDF

ELEMENTOS DE PROJETOS DE INFORMTICA
Edio n 1 - 2008
ROSEMARY FRANCISCO
Apoio
Gesto e Execuo
Contedo e Tecnologia
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 desenvolvimento de software; na segunda, as principais caractersticas do processo de desenvolvimento 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 surgir 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
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 software, 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 desenvolvimento 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, conhecermos 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 caractersticas 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
Informtica
_/_ a _/_
Introduo a UML
Introduo a Ferramentas
CASE
_/_ a _/_
Conhecendo os principais
diagramas da UML
_/_ a _/_
Conhecendo o Processo de
desenvolvimento de Software
_/_ a _/_
12
Modelando Projetos de
Software
_/_ a _/_
Tendncias do Processo de
Engenharia de Software
_/_ a _/_
12
Estudo de Caso: Modelando um

Projeto de Software
_/_ a _/_
_/_ 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; Introduo ao Processo de Desenvolvimento de Software; Principais Caractersticas do
Processo de desenvolvimento de Software; Introduo s melhores prticas de modelagem 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 Language (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 implementao 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 projetos 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 Software;
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 provisrio 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 considerado como um planejamento, com menos ou mais detalhes, dependendo da sua aplicao, 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-
10
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 projeto 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 elaborao e execuo de projetos para desenvolvimento
de software, porm muitas tcnicas que abordaremos podero ser utilizadas em outros projetos tanto de informtica, como um projeto de montagem de
uma rede de computadores, por exemplo, quanto de
outras reas. Em alguns casos, alguns ajustes podem 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 planejamento no for desenvolvido de maneira eficiente, o sucesso do projeto estar automaticamente comprometido.
11
Fique sabendo
Atualmente, existem vrios modelos que permitem auxiliar nas tarefas 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, dentro 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 pesquisa 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 entregue, porm o oramento e o prazo ultrapassam os limites estipulados, e, alm
disso, o software entregue possui menos funcionalidades do que o especificado.
Fracassados - O projeto cancelado em algum momento durante o desenvolvimento.

Veja na figura 1 o resultado do Chaos Research publicado at o ano de 2002.
12
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 crescendo 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 projetos, 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 palafundamentais mtodos ferramentas e pro- vra rebento como uma juno/unio entre a engenharia de sistemas e de hardwacedimentos que possibilita ao gerente o re. Com a unio destas duas engenharias
surgiu a Engenharia de Software.
controle do processo de desenvolvimento de
13
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 sculos. 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 projetaram o ENIAC: Eletronic Numeric Integrator And Calculator. Com
18000 vlvulas, o ENIAC conseguia fazer 500 multiplicaes por segundo. 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 refrigerao, 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-
14
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 descontroladamente;
Grande parte dos softwares era desenvolvida utilizando conceito de orientao 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 crebro 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 manutenes 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 conceitos 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;
15
Comearam a surgir as software houses, empresas dedicadas exclusivamente ao desenvolvimento de softwares;

O software era desenvolvido para ampla distribuio num mercado interdisciplinar, 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 software 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
16
crescente demanda de acesso instantneo a dados exigem muito dos desenvolvedores de software;
Essa era foi caracterizada pelo advento e pelo generalizado uso de microprocessadores, computadores pessoais e poderosas estaes de trabalho workstations 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 abordagens mais convencionais para o desenvolvimento de software em muitas reas
de aplicao;
As tcnicas de quarta gerao para o desenvolvimento de software mudaram a maneira como alguns segmentos da comunidade de software constroem
programas de computador;
Os sistemas especialistas e o software de inteligncia artificial finalmente saram do laboratrio para a aplicao prtica em problemas do mundo real.
17
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 afirmao pode ser feita, pois os softwares desenvolvidos atualmente esto fortemente
marcados pelas seguintes caractersticas:
A grande maioria dos softwares desenvolvida com base na arquitetura cliente-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 softwares 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 mantidos 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.
18
Portanto, a Engenharia de Software nasceu justamente para
minimizar os problemas que ocorrem no processo de desenvolvimento de software. Seu principal objetivo melhorar a qualidade
dos softwares e aumentar a produtividade e satisfao dos profissionais.
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 sucedido, 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 diretamente ligada s demais caractersticas e poder impactar no seu sucesso :
a) Durao
19
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, ferramentas 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.
20
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;
21
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 adequadamente 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 atividades da informtica, porm, naquela poca, era visto como algo feito de forma artesanal, 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
um projeto de informtica ou mesmo automao de atividades.

Com o passar do tempo, as utilidades
adquiridas por meio da relao hardware e

software se tornaram mais expressivas e o
A automao pode ser traduzida como

um procedimento que utiliza as tecnologias de sistemas de informao disponveis para substituir atividades manuais
de mo-de-obra por equipamentos, sistemas e mquinas com o objetivo principal
de aumento na produtividade.
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 destaque.

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-
22
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 desenvolvimento 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 desenvolvimento concentrado com base na engenharia. Tambm h a fase de desenvolvimento, 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 problemas 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
23
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 ideal, 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 escritos 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 software 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, dependendo 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
24
representao idealizada de um software a ser desenvolvido. Por meio dos modelos,

ser mais fcil compreender as funcionalidades e objetivo principal do sistema de software, 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 corrigilos 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 funcionamento e as necessidades de recursos para o desenvolvimento do software e corrigir 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
25
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 apresentar 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 funcionalidades 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 modelagem 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:
26
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, conseqentemente, as tcnicas de modelagem
eram mais simples: era a poca dos fluxogra-
Este termo significa direto ao

assunto ou direto ao que interessa.
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 foram 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 paradigma so Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rumbaugh, 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
27
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 chamados 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 modelagem com base na orientao a objetos. Os trs amigos, que tambm estavam envolvidos 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 utilizados na modelagem e, permitem representar os conceitos do paradigma da orientao a objetos.

A UML, segundo Booch (2005, p.14), uma linguagem destinada a:

Visualizar;
28
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 necessrios para a construo do sofware.

Assim como a linguagem dispe de elementos grficos, que possibilitam me-
lhor visualizao do funcionamento do software,

existem tambm artefatos que permitem detalhar
o funcionamento de forma textual. Existe um ditado
Um artefato pode ser traduzido

como um documento de modelagem de orientao a objetos.
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 atualizao do modelo, por exemplo, a engenharia reversa pode ser uma boa prtica a ser
utilizada.
29
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 detalhes 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 modelagem 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-
30
mas, no importando qual a linguagem de programao a ser utilizada na implementao 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 seguinte 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 visveis 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 paralelismo -, 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
31
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 hardware 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 comprometidas.

Portanto, todas as tentativas da engenharia de software que visam minimizar
essa complexidade no planejamento e desenvolvimento dos projetos, envolvem a definio de processos de desenvolvimento de software.

Um processo de desenvolvimento de software ou simplesmente, processo de
desenvolvimento compreende todas as atividades necessrias para definir, desenvolver, 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 desenvolvimento;
32
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 contribuir para este processo.
Exerccios Propostos
1) Assinale a alternativa incorreta:
a) O software surgiu com o objetivo de auxiliar o hardware nas atividades de manipulao da informao;
b) O software, assim como o hardware, pode ser desenvolvido de forma manufaturada;
c) O software geralmente desenvolvido sob medida;
b) O software um objeto lgico.
33
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 desenvolvimento, 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 tempo;
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 tempo;
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.
34
Aula 3
INTRODUO A FERRAMENTA
CASE
Nesta aula voc estudar sobre os conceitos bsicos

que envolvem as ferramentas CASE e quais so os tipos de ferramentas disponveis para suporte ao desenvolvimento 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;
35
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 especificamente 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 partes de um programa que no foram testadas;
Testes automticos: ferramentas que realizam testes automaticamente no sistema;
Gerenciamento de verses: ferramentas que permitem gerenciar as diversas
verses dos artefatos de software gerados durante o ciclo de vida de um sistema;
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
36
CASE que auxiliam no gerenciamento dos projetos de software. Esse tipo de ferramenta utilizado pelos gerentes de projeto e permite: desenvolver cronogramas de
tarefas, definio de custos do projeto, acompanhamento de prazos e custos do projeto, 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 mecnico 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 adicionadas caixa de ferramentas do Engenheiro de Software e que permitiro desenvolver o trabalho de forma mais produtiva. O aumento da produtividade ir, conseqentemente, 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:
37
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 organizaes 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
38
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 especfica 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;
39
Ferramentas de software bsico;

Ferramentas de garantia da qualidade;
Ferramentas de banco de dados;
Ferramentas de Anlise e Projeto;
Ferramentas de Programao;
Ferramentas de Integrao e Teste;
Ferramentas de Prototipao;
Ferramentas de Manuteno;
Ferramentas de Engenharia Reversa;
Ferramentas de prototipao so
ferramentas que permitem ao desenvolvedor criar um prottipo
modelo que ir representar
o layout das telas do sistema de
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 funcionalidades, 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.
40
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 integrao 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 modelagem 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 instalao, 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
41
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 campos obrigatrios com ateno e, ao final, clique no boto para confirmao do cadastro, 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-
42
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: [Download], 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 download 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;
43
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 transferncia do arquivo de instalao;
12. Finalizao o download, clique duas vezes em cima do arquivo: jude-community5_2b1-setup.exe para iniciar a instalao. Selecione o idioma ingls e clique no boto: [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;

44
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 preferir, 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 padro e clique no boto: [Next], conforme indica a figura 17;
45
17. A prxima tela seguinte questiona se voc deseja: (1) incluir um cone da ferramenta 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 selecionadas at agora. Valide as informaes e clique no boto: [Install] para iniciar a instalao da ferramenta.
19. A instalao ser iniciada conforme mostra a figura 20. Aguarde at o final da
instalao.
46
20. Finalizada a instalao, ser mostrada a tela conforme a figura 21. Clique no boto: [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
47
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;
48
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.
49
Aula 4
CONHECENDO OS PRINCIPAIS
DIAGRAMAS UML
Nesta quarta aula, vamos estudar quais so os elementos 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;
50
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 conceitos 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 mesmos 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
51
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 assumir 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
Estrutural
Nome
Figura
Classe
Ou
Estrutural
Interface
52
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
53
a criao de diversas vises como modelo para os projetos de software. No necessrio 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.
54
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 anotacionais -, 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 atuar.

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 relacionamento 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.
55
Tabela 2 Tipos de Relacionamentos

Nome
Funo
Representao
Elemento grfico: seta aberta tracejada Exemplo:
Dependncia
Relacionamento entre dois itens,

a alterao no item independente
pode afetar a semntica funcionamento do item dependente.
Relacionamento estrutural entre

classes que descrevem um conjunto de ligaes, em que as ligaes so conexes entre objetos
Associao
que so instncias das classes. A

agregao um tipo especial de
associao, representando um
relacionamento estrutural entre o
todo e suas partes.
Notao:
A classe Dependente depende estruturalmente
da classe Independente.
Elemento grfico: linha simples
Exemplo:
Notao:
Um departamento possui um ou mais funcionrios na sua hierarquia.
Elemento grfico: seta fechada
Exemplo:
Generalizao
Relacionamento de um elemento
mais geral e outro mais especfico. Os objetos da classe-filha
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 estrutura atributos e operaes da classe Atleta.
Classes Associativas
So classes ligadas a associaes, em vez de estarem ligadas a outras classes. Esse tipo
de classe normalmente aparece
quando duas ou mais classes
esto associadas e necessrio
manter informaes sobre associao.
Elemento grfico: classe ligada a uma associao por uma linha tracejada
Exemplo:
Classe associativa = Emprego
56
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
Caracterstica
Funo
Nome
Uma associao pode ter um

nome, que pode ser utilizado para
descrever a natureza do relacionamento.
Papel
Quando uma classe est em uma

associao, possui um papel especfico neste relacionamento.
Multiplicidade
importante determinar a quantidade (multiplicidade) de objetos

que podem ser conectados pela
instncia de uma conexo. A tabela 4 ilustra a simbologia para representar as multiplicidades.
Agregao
um tipo especial de associao

que ilustra a associao todo/parte. Toda ao realizada sobre a
classe todo afetar as classes
partes.
Composio
A composio um tipo especial

de agregao - agregao por valor. Semanticamente equivalente
a um atributo.
A remoo do todo implica na remoo das partes e o acesso s
partes restrito ao todo. Significa
que as classes/objetos indicadas
como partes de uma composio no estaro acessveis externamente, somente por meio da
classe/objeto todo.
Representao
Classe Pessoa
Classe Pessoa depois de utilizar composio
57
Tabela 4 Simbologia para representar multiplicidades

Nome
Simbologia
Apenas um
Zero ou Muitos
0..*
Um ou Muitos
1..*
Zero ou um
0..1
Os diagramas de classes so utilizados para
fazer a modelagem da viso esttica de um sistema. Essa viso oferece principalmente suporte
para os requisitos funcionais de um sistema os
Os requisitos funcionais e nofuncionais sero discutidos com

mais detalhes nos captulos 5 e
6.
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
58
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 importante na modelagem do comportamento de um sistema, por meio dele possvel
identificar de forma visual as funcionalidades do sistema e a interao destas funcionalidades 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 existem 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.
59
Tabela 5 Documentao de Caso de Uso

Caso de Uso:
Visualizar Avaliaes
Sumrio:
Aluno visualiza avaliao que recebeu notas e freqncia nas turmas

de um semestre letivo.
Ator Primrio:
Aluno
Ator Secundrio:
Professor
Pr-Condies:
O aluno est identificado pelo sistema.
Fluxo Principal:
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.
3. O aluno seleciona os semestres letivos cujas avaliaes deseja visualizar.
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
Fluxo de Exceo (2):
Ps-Condies:
1. No h semestre letivo no qual o aluno tenha participado em alguma

disciplina.
2. O sistema reporta o fato e o caso de uso termina.
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
60
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 principal, 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, Administradora 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: primrios 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.
61
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 seqncias 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 casos de uso e os relacionamentos
Fronteira do Sistema
Elemento grfico: boneco palito

Ator
Elemento grfico: elipse

Caso de Uso
62
Elemento grfico: linha simples

Relacionamento de Comunicao
Relacionamento de Incluso somente entre casos de uso
Relacionamento de Extenso somente entre

casos de uso
Elemento grfico: seta tracejada com esteretipo: <<include>>
Elemento grfico: seta tracejada com esteretipo: <<extend>>
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
63
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
64
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
65
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 acontece em algum ponto do tempo e pode modificar o
estado do objeto. Uma ao uma operao que
pode ser realizada pelo prprio objeto.
Elemento grfico: seta
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 ramificaes 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 possivelmente 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.
66
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
Estado inicial da atividade
Estado final da atividade
Representao
Elemento grfico: crculo preenchido
Elemento grfico: crculo elipsado
Elemento grfico: raias de natao
Atores envolvidos na atividade
Elemento grfico: retngulo arredondado

Ao dos atores nas atividades
67
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 software;
4) As caractersticas, objetivos e representao de cada um destes diagramas.
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
68
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 compartilhado 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 diagrama de:
a) Classes
b) Casos de Uso
c) Atividades
d) Seqncia
69
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 desenvolvimento 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.
70
1 INTRODUO AO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Um Processo de desenvolvimento de software pode ser considerado como um conjunto 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.
71
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 desejado 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 requisitos 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 atividade, 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 software, como tambm com o hardware bsico ou com o sistema operacional.
4. Implementao (ou codificao) a atividade responsvel pelo desenvolvimento do projeto do software efetivamente. nessa atividade que o software comear a ser construdo e codificado por meio de linguagens de programao 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 atividade 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 funcionalidades.
6. Documentao atividade que se refere documentao do projeto interno do software para propsitos de futuras manutenes e aprimoramentos. As
documentaes mais importantes so das interfaces externas. Grande parte
72
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, principalmente para descrever e/ou detalhar as instrues que so utilizadas para implementar as funcionalidades do sistema.
7. Suporte e Treinamento de Software uma grande porcentagem dos projetos 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 descoberta 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 trabalhar 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 consideradas um novo trabalho.

A figura 29 ilustra as atividades do processo de desenvolvimento de software e
a interao entre elas.
73
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 Standardization, 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 forma a melhor-los. Seu principal objetivo fornecer uma estrutura comum para
que os envolvidos com o desenvolvimento de software, utilizem uma linguagem comum.
SPICE a ISO/IEC 15504, tambm conhecida como SPICE, a norma ISO/
74
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 pequenas e mdias empresas de desenvolvimento de software no Brasil. baseado 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, custo, 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 desenvolvimento 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-
75
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.
76
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 abrangentes 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 fundamentos 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 partes 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
77
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 considerado 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
78
Sntese da Aula


1) O processo de desenvolvimento de software e as suas principais caractersticas;
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 diretamente nas demais atividades de software :
a) Anlise de requisitos de software;
79
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.
80
Aula 6
MODELANDO PROJETOS DE
SOFTWARE
Nesta sexta aula voc estudar sobre as principais atividades 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;
81
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, desenvolver 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 necessidade. 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.
82
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 informaes 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.
83
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 entrevista com o usurio.
Tabela 10 Exemplo de Questionrio
1.
2.
3.
4.
Qual o objetivo do Sistema?

Que rea vai atender?
Que tipo e quantos usurios estaro interagindo com o sistema?
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
84
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 usurios 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, mensais 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 querem / 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 autorizados.
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-
85
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 celular, 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 termos 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: visualizao 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

disciplinas por semestre letivo.
Requisito Funcional
O sistema deve permitir o lanamento das notas dos alunos por disciplina pelos professores.
Requisito Funcional
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.
Requisito Funcional
O sistema deve ser desenvolvido para a plataforma WEB
Requisito No-Funcional
86
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 sistema.

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 informao no sistema?
4. O ator precisa ser informado sobre eventos que acontecem no sistema?
5 .O ator precisa notificar o sistema de alguma coisa?
87
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 textualmente. O detalhamento do caso de uso geralmente utilizado quando a funcionalidade 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 sugerido 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.
88
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 instrues:
1. Abra a ferramenta por meio do menu: Iniciar >> Programas >> JUDE Community;
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 diagramas podendo ser vrias verses de um mesmo diagrama dessa forma,
sempre coloque um nome para os diagramas identificando a situao ou funcionalidade 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 disponvel apenas no idioma ingls, segue abaixo a traduo para os principais
diagramas UML:
a) Diagrama de Caso de Uso = UseCase Diagram
89
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 necessrio, 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 quantidade 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 classes 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 funcionalidades 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 utilizados?
4. Existem informaes que devem ser manipuladas de qualquer forma? Quais?
(Detalhar atributos e operaes)
5. Existem representaes organizacionais?
90
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.
91
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 definio 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.
92
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 considervel 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-
93
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
94
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 software;
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 modelagem de projetos de software.
95
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 cadastrar Clientes contendo os dados: nome,

endereo, e telefone
Requisito Funcional
O sistema deve permitir ao Funcionrio cadastrar Cidades que representam os lugares

abrangidos pela empresa de transportes e
contm o nome da cidade, o estado a que
pertence e o valor para a taxa de entrega
Requisito Funcional
O sistema deve permitir ao Funcionrio cadastrar Fretes contendo um cdigo, uma descrio, 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
Requisito Funcional
O sistema deve ser para plataforma WEB
96
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 comunidade 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;
97
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 servios 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 disponvel 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 surgir. O objetivo dessas mudanas sempre a melhoria no processo de desenvolvimento de projetos de software a fim de produzir softwares com maior produtividade e
98
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 coerente. 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 beneficiadas, 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 desenvolvimento de sistemas de software orientados a objetos. Um padro de projeto estabelece um
99
nome e define o problema, a soluo, quando aplicar essa soluo e suas conseqncias.

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, documentao 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 Iterative 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, tcnicas 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 vezes 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
100
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 pequeno 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 valorizar:
Indivduos e interaes so mais importantes que processos e ferramentas;
Software funcionando mais importante do que documentao detalhada;
Colaborao dos clientes mais importante do que negociao de contratos;
Adaptao s mudanas mais importante do que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.

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 pequenas 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 pesquisa e at em agncias governamentais. Algumas das metodologias geis existentes
101
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 Componentes;
3) Conceitos bsicos sobre Padres de Projeto;
4) Conceitos bsicos sobre Metodologias geis.
102
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.
103
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 modelagem 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.
104
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 sistemas 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 software.
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 documento 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:
105
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
Requisito Funcional
O sistema deve permitir que o gerente cadastre profissionais
Requisito Funcional
O sistema deve permitir que o gerente realize o cadastro de servios utilizados em uma festa de casamento,
como buffet e carros utilizados
Requisito Funcional
O sistema dever permitir que o cliente realize o cadastro da lista de convidados
Requisito Funcional
O sistema dever permitir que o cliente elabore a configurao da festa
Requisito Funcional
O sistema dever permitir a gerao do oramento

para o cliente
Requisito Funcional
O sistema dever permitir que o gerente realize a impresso de relatrio de festas
Requisito Funcional
O sistema dever permitir que o cliente cadastre a lista

de presentes
Requisito Funcional
O sistema dever permitir que o gerente realize o cadastro de usurios
Requisito Funcional
10
O sistema dever permitir a autenticao dos usurios
Requisito Funcional
11
O sistema deve ser compatvel com os navegadores

Internet Explorer e Firefox
12
O sistema deve garantir que o tempo de retorno das consultas seja inferior a 5 segundos
106
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 funcionalidades 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.
107
Tabela 13 Especificao do Caso de Uso: Autentica Usurio

Caso de Uso:
Autentica Usurio
Sumrio:
Efetuar o login dos usurios no sistema de acordo com o perfil de cada

um e exibir as telas permitidas para cada perfil.
Ator Primrio:
Gerente
Ator Secundrio:
Cliente
Pr-Condio:
Usurio acessa o sistema
Fluxo Principal:
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 usurio [A2].
4. O sistema autentica o usurio e apresenta a tela com as opes que
ele pode acessar.
5. Caso de uso encerrado.
Fluxo Alternativo:
A1. Usurio seleciona a opo: Cancelar

a. Caso de Uso encerrado
A2. Login ou senha invlida
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

108
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 armazenados 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.
109
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 proposto, 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-
110
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
111
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 surgiram; 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 produto 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 profissional 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.
112
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/
113
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 seguintes 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 telefone;
2. VOC informa ao ATENDENTE seus dados e as caractersticas da pizza que deseja 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
114
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.
115
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 objetos, 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.
116
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, essas caractersticas so implementadas atravs de variveis.
117
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.
118
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

Rua Albano Schmidt, 3333 Joinville SC 89206-001
Fone: (47)3461-0166
E-mail: ead@sociesc.org.br
Site: www.sociesc.org.br/portalead
Diretor Geral
Sandro Murilo Santos
Diretor de Administrao
Vicente Otvio Martins de Resende
Diretor de Ensino, Pesquisa e Extenso
Roque Antonio Mattei
Diretor do Instituto Superior Tupy
Wesley Masterson Belo de Abreu
Diretor da Escola Tcnica Tupy
Luiz Fernando Bublitz
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
Professor Responsvel
Rosemary Francisco
EDIO MATERIAL DIDTICO

Professor Conteudista
Rosemary Francisco
Design Institucional
Cristiane Oliveira
Ilustrao Capa
Projeto Grfico
Equipe Tupy Virtual
Reviso Ortogrfica
Ndia Ftima de Oliveira

Apostilaelementosdeprojetodeinformtica 140716194941 Phpapp01 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

Apostilaelementosdeprojetodeinformtica 140716194941 Phpapp01 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ELEMENTOS DE PROJETOS DE INFORMTICA

Elementos de Projetos de Informtica

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

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

Para sua melhor compreenso, o livro est estruturado em quatro partes: na

primeira, apresentaremos os conceitos bsicos sobre projetos de informtica e os

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

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

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

principais elementos para o desenvolvimento de projetos de informtica, em especial,

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

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

Porm, no so somente as Fbricas de Software que utilizam as tcnicas de

modelagem e desenvolvimento de software, todas as empresas que possuem em

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

Portanto, muito importante que o profissional de informtica conhea as

tcnicas e saiba aplic-las corretamente durante o desenvolvimento de projetos de

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

Professora Rosemary Francisco

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

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

sveis datas de realizao de aprendizagem e avaliaes.

Estudo de Caso: Modelando um

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

Ao final desta aula voc dever ser capaz de:

Acompanhe os contedos desta aula. Se voc preferir, assi-

nale-os medida em que for estudando.

Conceitos Bsicos de Engenharia de Software;

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

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

Analisando os significados indicados pelo Dicionrio Aurlio, podemos ento

Ao analisarmos o contexto de nossas prprias vidas, podemos identificar vrios

elementos que se assemelham aos projetos. Um exemplo simples que podemos

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

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

As principais caractersticas de um projeto so:

Durao tempo estimado para incio e fim do projeto

Custo valor do projeto no total

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

SOCIESC - Sociedade Educacional de Santa Catarina

Elementos de Projetos de Informtica

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.