Apostila Elementos de Projeto de Informática

ELEMENTOS DE PROJETOS DE INFORMÁTICAEDIçÃO Nº 1 - 2008

ROSEMARY FRANCISCO

Apoio Gestão e Execução Conteúdo e Tecnologia

Elementos de Projetos de Informática2

SOCIESC - Sociedade Educacional de Santa Catarina

Apresentação

Este livro didático contém a disciplina de Elementos de Projetos de Informá-

tica.

O conteúdo deste livro irá disponibilizar aos alunos do EAD os conceitos funda-

mentais sobre o processo de desenvolvimento de projetos de informática. Por meio

deste material, será possível conhecer as fases do processo de desenvolvimento de

software e as melhores práticas que possibilitam: identificar e analisar um problema,

modelar a solução deste problema e, também, como gerenciar todas as fases deste

processo durante a evolução de um projeto.

Para sua melhor compreensão, o livro está estruturado em quatro partes: na

primeira, apresentaremos os conceitos básicos sobre projetos de informática e os

dois principais elementos que serão utilizados durante o processo de desenvolvimen-

to de software; na segunda, as principais características do processo de desenvol-

vimento de software e os diagramas da UML mais utilizados durante o processo; na

terceira parte, demonstraremos os passos para iniciar o desenvolvimento de projetos

de software, mostrando as principais técnicas utilizadas para iniciar um projeto e fazer

o correto acompanhamento durante a evolução das fases de desenvolvimento; na

quarta e última parte do livro, desenvolveremos um estudo de caso que permitirá a

consolidação dos conhecimentos adquiridos nesta disciplina.

Lembre-se de que a sua passagem por esta disciplina será acompanhada tam-

bém pelo Sistema de Ensino Tupy Virtual, seja por correio postal, fax, telefone, e-mail

ou Ambiente Virtual de Aprendizagem. Entre sempre em contato conosco quando sur-

gir alguma dúvida ou dificuldade.

Toda a equipe terá a maior alegria em atendê-lo, pois seu crescimento intelec-

tual e profissional, nessa jornada, é o nosso maior objetivo.

Acredite no seu sucesso e bons momentos de estudo!

Equipe Tupy Virtual

Elementos de Projetos de Informática 3


SUMÁRIO

CARTA DA PROFESSORA ........................................................................................ 4

CRONOGRAMA DE ESTUDOS ................................................................................. 6

PLANO DE ESTUDOS ................................................................................................ 7

Aula 1 – Introdução a Projetos de Informática ....................................................... 8

Aula 2 – Introdução a UML ..................................................................................... 20

Aula 3 – Introdução a Ferramentas CASE............................................................. 34

Aula 4 – Conhecendo os principais diagramas UML ........................................... 49

Aula 5 – Conhecendo o Processo de Desenvolvimento de Software ................ 69

Aula 6 – Modelando Projetos de Software ............................................................ 80

Aula 7 – Tendências do Processo de Engenharia de Software .......................... 96

Aula 8 – Estudo de Caso: Modelando um Projeto de Software ........................ 103

Referências .............................................................................................................112

Apêndice 1 – Revisão Paragima Orientação a Objetos ......................................113



Carta da Professora

Caro(a) aluno(a),

Nos próximos capítulos, terá início a caminhada rumo ao conhecimento dos

principais elementos para o desenvolvimento de projetos de informática, em especial,

os projetos de desenvolvimento de software. Para desenvolver um projeto de sof-

tware, assim como projetos de outras áreas de conhecimento, como engenharia civil,

por exemplo, é necessário que os profissionais envolvidos conheçam grande parte

das informações relacionadas ao projeto e, principalmente, compreendam qual é o

problema que deve ser resolvido. Porém, como um software é um objeto abstrato, o

resultado final não é palpável como uma casa ou um edifício, seu processo de desen-

volvimento é considerado complexo.

O processo de desenvolvimento de software tem sido aprimorado desde o iní-

cio da década de 1980 e, ainda hoje, há várias discussões e constantes grupos de

pesquisa para aperfeiçoamento de técnicas que possam contribuir com melhorias

para esse processo.

Com a evolução do paradigma da Orientação a Objetos, o processo de desen-

volvimento de software começou a se beneficiar de novas técnicas de modelagem de

software - como a linguagem UML - que surgiram para auxílio no desenvolvimento

e também para a minimização da complexidade que envolve o desenvolvimento de

sistemas de softwares. Essas técnicas vêm sendo utilizadas com bastante ênfase,

principalmente nas empresas denominadas: Fábricas de Software – empresas cujo

negócio é o desenvolvimento de projetos de software diversos para outras empresas,

independente do tipo de software.

Porém, não são somente as Fábricas de Software que utilizam as técnicas de

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

sua estrutura uma área de desenvolvimento de projetos de software, também estão

fazendo uso dessas técnicas para garantir o sucesso da solução empregada para a

resolução dos problemas identificados.



Portanto, é muito importante que o profissional de informática conheça as

técnicas e saiba aplicá-las corretamente durante o desenvolvimento de projetos de

software. Assim, nosso objetivo maior, depois de percorrida esta caminhada, é co-

nhecermos os principais elementos que estarão inseridos em projetos de software e

também quais as melhores práticas para o desenvolvimento desses projetos.

Durante esta caminhada, conheceremos: a origem dos projetos de software, o

que é e quais os benefícios de utilizar a UML em projetos de software, conhecer o que

são as ferramentas CASE e como podemos utilizá-las em conjunto com a UML; como

é a estrutura do Processo de Engenharia de Software e quais suas principais caracte-

rísticas e, ao final, desenvolveremos um estudo de caso com o intuito de praticarmos

melhor o conhecimento adquirido.

Sendo assim, convido você para, juntos, agora virtualmente, vencer este novo

desafio!

Professora Rosemary Francisco



Cronograma de Estudos

Acompanhe no cronograma abaixo os conteúdos das aulas, e atualize as pos-

síveis datas de realização de aprendizagem e avaliações.

Semana Carga horária Aula Data/ Avaliação

1

4 Introdução a Projetos de Informática _/_ a _/_

4 Introdução a UML _/_ a _/_

8 Introdução a Ferramentas CASE _/_ a _/_

28 Conhecendo os principais

diagramas da UML _/_ a _/_

8 Conhecendo o Processo de desenvolvimento de Software _/_ a _/_

312 Modelando Projetos de

Software

_/_ a _/_

4 Tendências do Processo de Engenharia de Software _/_ a _/_

4 12 Estudo de Caso: Modelando um Projeto de Software _/_ a _/_



Plano de Estudos

Ementa

Introdução a projetos de desenvolvimento de software; Visão geral da linguagem

UML; Principais Diagramas da Linguagem UML; Introdução a ferramentas CASE; In-

trodução ao Processo de Desenvolvimento de Software; Principais Características do

Processo de desenvolvimento de Software; Introdução às melhores práticas de mo-

delagem e desenvolvimento do software; Projetar, gerenciar e implementar sistemas

de Software.

Objetivos da Disciplina

• Geral

Capacitar o aluno com os conhecimentos básicos do processo de desenvolvimento

de software que permitirão aprender a: analisar, projetar e implementar sistemas de

software.

• Específicos

• Introduzir os conceitos básicos de projetos de software

• Apresentar a linguagem de modelagem padrão de mercado Unified Modeling Lan-

guage (UML) largamente utilizada para a Análise e Projeto de sistemas de software

• Apresentar um processo completo de desenvolvimento de software utilizável com a

linguagem UML

• Demonstrar as principais características das ferramentas CASE

• Instalar e configurar uma ferramenta CASE

• Apresentar técnicas e ferramentas básicas para análise, gerenciamento e implemen-

tação de projetos de software

• Desenvolver a modelagem de um estudo de caso para consolidar os conhecimentos

da disciplina

Carga Horária: 60 horas/aula.



Aula 1

INTRODUÇÃO A PROJETOS DE INFORMÁTICA

Nesta aula você estudará os conceitos básicos de pro-

jetos de informática e Engenharia de Software e como

a Engenharia de Software poderá auxiliar no desenvolvimento e

manutenção de sistemas de software.

Bom estudo!

Objetivos da Aula

Ao final desta aula você deverá ser capaz de:

• Apontar as características de um projeto de informática;

• Identificar os conceitos básicos da Engenharia de Softwa-

re;

• Identificar os objetivos da Engenharia de Software.

Conteúdos da Aula

Acompanhe os conteúdos desta aula. Se você preferir, assi-

nale-os à medida em que for estudando.

• O Projeto de Informática;

• Conceitos Básicos de Engenharia de Software;

• Exercícios propostos.



1 O QUE É PROJETO DE INFORMÁTICA

Antes de compreendermos o que é um projeto de informática, é importante sa-

bermos a definição de projeto como um todo. De acordo com o Dicionário Aurélio, há

cinco significados para a palavra projeto:

1. Idéia que se forma de executar ou realizar

algo, no futuro; plano, intento, desígnio.

2. Empreendimento a ser realizado dentro de

determinado esquema: projeto administrativo;

projetos educacionais.

3. Redação ou esboço preparatório ou provi-

sório de um texto: projeto de estatuto; projeto

de tese.

4. Esboço ou risco de obra a se realizar; plano:

projeto de cenário.

5. Plano geral de edificação.

Analisando os significados indicados pelo Dicionário Aurélio, podemos então

compreender que um projeto, independente do tipo de aplicação, pode ser considera-

do como um planejamento, com menos ou mais detalhes, dependendo da sua aplica-

ção, que poderá auxiliar na execução e avaliação do resultado obtido ao final de sua

execução.

Ao analisarmos o contexto de nossas próprias vidas, podemos identificar vários

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

utilizar é o planejamento de uma viagem de turismo. Para realizarmos uma viagem

de turismo é necessário sabermos: o local destino da viagem, o custo dessa viagem,

a forma de transporte, a forma de hospedagem, a melhor época para realização da

viagem, entre outros. Além disso, ao planejar uma viagem de turismo, precisamos

saber quando poderemos realizá-la e também se temos condições financeiras para

realizá-la, lembrando sempre que uma viagem que dura um final de semana possui

um planejamento bem mais simples do que outra que dura em torno de 10 dias. Por-



tanto, independente do tipo de projeto que se deseja realizar, é muito importante saber

qual será a duração, em outras palavras, quando é o início e o fim da realização do

projeto.

Os projetos de informática possuem várias características que se assemelham

a um projeto de turismo, porém no projeto de informática – como é o caso do software

– o produto é abstrato, motivo pelo qual a elaboração e a condução desse tipo de pro-

jeto se torna muito mais complexo devido ao grande número de variáveis que podem

modificar a estrutura do projeto e, conseqüentemente, seu resultado final.

Neste módulo, focalizaremos principalmente a elabo-

ração e execução de projetos para desenvolvimento

de software, porém muitas técnicas que abordare-

mos poderão ser utilizadas em outros projetos tan-

to de informática, como um projeto de montagem de

uma rede de computadores, por exemplo, quanto de

outras áreas. Em alguns casos, alguns ajustes po-

dem ser necessários, mas em um contexto geral, a

parte de análise e detalhamento do projeto pode ser

disseminada para outros tipos de projetos.

1.2 PRINCIPAIS CARACTERÍSTICAS DE UM PROJETO

As principais características de um projeto são:

• Duração – tempo estimado para início e fim do projeto

• Custo – valor do projeto no total

• Planejamento – de que forma e com quais recursos será desenvolvido o

projeto.

• Qualidade – resultado obtido na finalização do projeto

A característica Planejamento, além de estar diretamente relacionada com Du-

ração e Custo, também irá refletir na Qualidade do projeto. Portanto, se o planejamen-

to não for desenvolvido de maneira eficiente, o sucesso do projeto estará automatica-

mente comprometido.



Fique sabendo

Atualmente, existem vários modelos que permitem auxiliar nas ta-refas de planejamento e gerenciamento de projetos. Os modelos

mais populares são: PMBOK um guia de gerenciamento criado pelo PMI - Project Manegement Institute – http://www.pmi.org/ ; Processo

Unificado - UP – criado pelos autores da linguagem UML - Grady Booch, James Rumbaugh e Ivar Jacobson; MSF – Microsoft Solutions Framework; e, den-tro dos conceitos de desenvolvimento Ágil: SCRUM, Extreme Programming, entre outros.

1.3 RESULTADO DOS PROJETOS DE SOFTWARE

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

intitulado de “Chaos Research” que consolida as informações de uma grande pesqui-

sa sobre sucessos e fracassos dos projetos de software. Nesse estudo, os resultados

dos projetos são classificados da seguinte maneira:

• Bem sucedidos - O projeto é finalizado no prazo, dentro do orçamento e

contendo todas as funcionalidades especificadas.

• Comprometidos - O projeto é finalizado e um software operacional é entre-

gue, porém o orçamento e o prazo ultrapassam os limites estipulados, e, além

disso, o software entregue possui menos funcionalidades do que o especifica-

do.

• Fracassados - O projeto é cancelado em algum momento durante o desen-

volvimento.

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



Figura 1 – Resultado do Chaos Research até o ano de 2002

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

derados Bem sucedidos aumentou consideravelmente desde 1994, quando apenas

16% dos projetos realizados eram bem sucedidos. A partir daí, esse número foi cres-

cendo e, em 2002, a quantidade de projetos bem sucedidos chegou a 34%.

De qualquer forma, podemos verificar que ainda é muito grande a quantidade

de projetos que não são bem sucedidos. Podemos verificar também que a grande

maioria dos projetos está na categoria dos comprometidos, tiveram problemas no

planejamento como custo além do esperado, ou ainda com uma duração muito maior

do que a estipulada.

De posse dessas informações, podemos concluir que é imprescindível aos pro-

fissionais de informática, em especial os desenvolvedores de software, a utilização

das melhores técnicas da Engenharia de Software para planejar e conduzir seus pro-

jetos, dessa forma, a garantia de projetos Bem Sucedidos será consideravelmente

maior.

2 O QUE É ENGENHARIA DE SOFTWARE

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

Ela abrange um conjunto de três elementos

fundamentais – métodos ferramentas e pro-

cedimentos – que possibilita ao gerente o

controle do processo de desenvolvimento de

Neste contexto podemos traduzir a pala-vra rebento como uma junção/união en-tre a engenharia de sistemas e de hardwa-re. Com a união destas duas engenharias surgiu a Engenharia de Software.



software e oferece ao profissional uma base para a construção de software de alta

qualidade produtivamente” (PRESSMAN, 1995, p. 31).

Analisando a definição de engenharia de software feita por Pressman, pode-

mos interpretá-la como um conjunto de métodos, ferramentas e técnicas que auxiliam

os profissionais no desenvolvimento dos projetos de software.

Mas...

Por que é necessária a utilização da Engenharia de Software nos projetos de

software?

Antes de responder esta questão, é importante analisarmos um pouco alguns

dados históricos a respeito do desenvolvimento de software.

Como já sabemos, a informática é uma ciência muito nova ainda, em relação a

outras ciências como medicina e direito, por exemplo, que já existem há alguns sécu-

los. Se relembrarmos os fatos históricos sobre a colonização do Brasil, veremos que,

naquela época, já existiam profissionais de medicina e de direito. A informática ainda

não completou um século de existência, o primeiro computador, o ENIAC, foi criado

em 1946.

Fique sabendo

O engenheiro John Presper Eckert e o físico John Mauchly proje-taram o ENIAC: Eletronic Numeric Integrator And Calculator. Com

18000 válvulas, o ENIAC conseguia fazer 500 multiplicações por se-gundo. Os custos para a manutenção e conservação do ENIAC eram

absurdos, pois dezenas a centenas de válvulas queimavam a cada hora e o calor gerado por elas necessitava ser controlado por um complexo sistema de refri-geração, além dos gastos elevadíssimos de energia elétrica. (WIKIPÉDIA)

Antes do ENIAC, já havia alguns recursos e Ferramentas

de informática, mas eram utilizadas somente por militares, que

fizeram uso dessa tenologia durante as duas grandes guerras

mundiais. Após a criação do ENIAC, a informática começou a

ser utilizada em outros cenários, como a indústria.

Na década de 50, deu-se início ao software, cuja evolu-



ção é possível verificar na figura 2.

Figura 2 – Evolução do Software

A primeira era da evolução do software teve início nos anos 1950 e se estendeu

até meados de 1965. Nesta era o software possuía as seguintes características:

• O desenvolvimento do software era feito sem nenhum tipo de planejamento,

até que os prazos começassem a se esgotar e os custos a subir descontrola-

damente;

• Grande parte dos softwares era desenvolvida utilizando conceito de orienta-

ção “batch” (atividades em lote);

• O hardware dedicava-se à execução de um único programa que, por sua vez,

dedicava-se a uma única aplicação específica;

• O software era projetado sob medida para cada aplicação e tinha distribuição

relativamente limitada;

• Geralmente o projeto do software era um processo implícito, realizado no cé-

rebro de alguém, e a documentação muitas vezes não existia.

De acordo com as características da primeira era da evolução do software,

podemos imaginar a complexidade que deveria ser desenvolver e depois realizar ma-

nutenções nos softwares desenvolvidos naquela época.

A segunda teve início em 1965 e se estendeu até 1975. Essa era foi marcada

pelas seguintes características:

• A multiprogramação e os sistemas multiusuários introduziram novos concei-

tos de interação homem-máquina;

• Teve início a utilização de técnicas interativas;

• Os avanços da armazenagem on-line levaram à primeira geração de sistemas

de gerenciamento de banco de dados;



• Começaram a surgir as “software houses“, empresas dedicadas exclusiva-

mente ao desenvolvimento de softwares;

• O software era desenvolvido para ampla distribuição num mercado interdisci-

plinar, início do conceito de produto de software;

• Os softwares eram geralmente programas desenvolvidos para mainframes e

minicomputadores;

• Surgimento da “manutenção de software”.

Na segunda era, podemos observar que houve um salto bem grande na evo-

lução do desenvolvimento de software. Foi nessa época que começaram a surgir as

primeiras idéias para o desenvolvimento de Sistemas Gerenciadores de Banco de

Dados, tecnologia muito utilizada atualmente no desenvolvimento de software.

Nessa época também começaram a surgir as empresas dedicadas exclusiva-

mente ao desenvolvimento de software e produtos de software, os chamados softwa-

re de prateleira.

A terceira era, que teve início em 1975 e foi até 1985, foi marcada pelas seguin-

tes características:

• As redes globais, as comunicações digitais de largura de banda elevada e a



crescente demanda de acesso “instantâneo” a dados exigem muito dos desen-

volvedores de software;

• Essa era foi caracterizada pelo advento e pelo generalizado uso de micropro-

cessadores, computadores pessoais e poderosas estações de trabalho “works-

tations” de mesa.

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

Sistemas Distribuídos e Inteligência Artificial começaram a surgir. Já tivemos

grandes avanços, mas como a aplicação desses conceitos é muito ampla, ainda hoje

existem muitos estudos e pesquisas sendo desenvolvidos.

Por fim, a quarta era, que iniciou em 1985, foi marcada pelas seguintes carac-

terísticas:

• As tecnologias orientadas a objetos começaram a ocupar o lugar das aborda-

gens mais convencionais para o desenvolvimento de software em muitas áreas

de aplicação;

• As técnicas de “quarta geração” para o desenvolvimento de software muda-

ram a maneira como alguns segmentos da comunidade de software constroem

programas de computador;

• Os sistemas especialistas e o software de inteligência artificial finalmente saí-

ram do laboratório para a aplicação prática em problemas do mundo real.



De acordo com as características da quarta era da evolução do software, pode-

mos perceber que vivemos uma nova era do desenvolvimento de software. Esta afir-

mação pode ser feita, pois os softwares desenvolvidos atualmente estão fortemente

marcados pelas seguintes características:

• A grande maioria dos softwares é desenvolvida com base na arquitetura clien-

te-servidor;

• O desenvolvimento de softwares para ambiente WEB está cada vez mais

comum;

• Introdução do conceito de serviços, pequenas aplicações específicas para um

determinado fim, está se propagando;

• Grande evolução dos sistemas gerenciadores de banco de dados, permitindo

a integração entre o banco de dados e sistemas disponíveis na internet;

• Preocupação com qualidade no desenvolvimento e planejamento dos softwa-

res fez surgir vários modelos e técnicas.

Assim, ao analisar a evolução no desenvolvimento de software, fica mais fácil

compreender a real necessidade da Engenharia de Software.

Vimos que, com o passar do tempo, muitos conceitos e tecnologias surgiram,

sempre com o intuito de abranger ou então suprir deficiências dos processos manti-

dos pelos softwares da época. No início, como o software era desenvolvido de forma

artesanal, seu custo e problemas por falta de planejamento era muito elevado.



Portanto, a Engenharia de Software nasceu justamente para

minimizar os problemas que ocorrem no processo de desenvolvi-

mento de software. Seu principal objetivo é melhorar a qualidade

dos softwares e aumentar a produtividade e satisfação dos profis-

sionais.

Síntese da Aula

Nesta aula estudamos:

• Introdução ao conceito de projeto de informática;

• Principais características de projetos de informática;

• Conceito e características de Engenharia de Software;

• A evolução do desenvolvimento de Software.

Exercícios Propostos

1) Assinale a alternativa correta. Para que um projeto de software seja bem su-

cedido, é imprescindível o cumprimento das seguintes características:

a) Prazo, Qualidade, Planejamento;

b) Custo, Prazo, Planejamento;

c) Custo, Prazo, Funcionalidades;

d) Funcionalidades, Prazo, Planejamento.

2) Selecione a alternativa correta. A característica de projeto que está diretamen-

te ligada às demais características e poderá impactar no seu sucesso é:

a) Duração



b) Qualidade

c) Prazo

d) Planejamento

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

a) Auxiliar somente no planejamento do projeto de software;

b) Auxiliar no desenvolvimento de todo o projeto de software, utilizando técnicas, fer-

ramentas e procedimentos;

c) Disponibilizar técnicas e ferramentas para a construção do software;

d) Disponibilizar ferramentas para o desenvolvimento de software.

3) Qual das alternativas abaixo é uma característica específica da era atual de

desenvolvimento de software?

a) Utilização de gerenciadores de banco de dados;

b) Utilização de inteligência artificial;

c) Utilização de arquitetura cliente-servidor;

d) Utilização de ambiente WEB.



Aula 2

INTRODUÇÃO A UML

Nesta segunda aula você estudará o que é modelagem

de software e qual a sua importância dentro de um

projeto de software. Também vamos estudar o que é a linguagem

UML, seu histórico, suas principais características e, por fim, como

esta linguagem pode auxiliar na modelagem de software.

Bom estudo!

Objetivos da Aula

Ao final desta aula, você deverá ser capaz de:

• Descrever a importância da modelagem;

• Identificar os conceitos básicos da UML;

• Descrever como a UML pode auxiliar na modelagem.

Conteúdos da Aula



• Modelagem de Software;

• Introdução a UML;

• UML e o Processo de Desenvolvimento de Software;




1 MODELAGEM DE SOFTWARE

Para que possamos compreender o que é e qual a importância da modelagem

de software, vamos primeiro analisar o que é o software, como surgiu e quais as suas

principais características.

De acordo com PRESSMAN (1995, p. 12), podemos definir didaticamente o

software das seguintes maneiras:

1. Instruções (programas de computador) que, quando executadas, produzem

a função e o desempenho desejados;

2. Estruturas de dados que possibilitam que os programas manipulem adequa-

damente a informação;

3. Documentos que descrevem a operação e o uso dos programas.

Se analisarmos novamente a figura 2 (pág. 14) – Evolução do Software – da

aula 1, veremos que o software surgiu com o objetivo principal de suporte às ativida-

des da informática, porém, naquela época, era visto como algo feito de forma artesa-

nal, sem grande importância e poucos possuíam o conhecimento de uma linguagem

de desenvolvimento. O importante mesmo, na época, era o hardware, que também

detinha grande parte dos custos dentro de

um projeto de informática ou mesmo auto-

mação de atividades.

Com o passar do tempo, as utilidades

adquiridas por meio da relação hardware e

software se tornaram mais expressivas e o

software começou a se tornar uma peça fundamental para os projetos de sistemas

de informação. Já não era mais possível desenvolver de forma artesanal, pois toda

responsabilidade em torno da manipulação dos dados ficou a cargo do software. É

justamente nesse momento, que a Engenharia de Software ganhou seu lugar de des-

taque.

Diferente do desenvolvimento de um hardware, que é um objeto físico, o sof-

tware é um objeto abstrato, em outras palavras, um objeto lógico. As principais carac-

A automação pode ser traduzida como um procedimento que utiliza as tecnolo-gias de sistemas de informação disponí-veis para substituir atividades manuais de mão-de-obra por equipamentos, siste-mas e máquinas com o objetivo principal de aumento na produtividade.



terísticas que diferenciam o software do hardware são:

• O sofware é desenvolvido ou projetado por engenharia, não manufaturado no

sentido clássico;

• O software não se desgasta;

• A maioria dos softwares é feita sob medida em vez de ser montada a partir de

componentes existentes.

A primeira característica citada por PRESSMAN indica que, diferente de um

produto de hardware – que também utiliza a engenharia durante o seu desenvolvi-

mento em um dado momento – esse objeto passa do modelo lógico – esboços e

desenhos da idéia feitos no papel – para algo palpável e manufaturado, construído em

um ambiente de produção, com auxílio de máquinas, equipamentos e pessoas desse

ambiente de produção. Já no desenvolvimento do software, todo o seu desenvolvi-

mento é concentrado com base na engenharia. Também há a fase de desenvolvimen-

to, qquando os programas e instruções são escritos, porém todas as fases de projeto

do software são baseadas em métodos e ferramentas da engenharia de software.

A segunda característica é realmente perceptível. O software jamais se desga-

ta, pode ficar ultrapassado, porém nunca diminuirá seu desempenho ou terá proble-

mas nas suas funcionalidades. Já o hardware, de acordo com o tempo de uso, poderá

mostrar falhas ou até parar de funcionar. As figuras 3 e 4 ilustram as diferenças na

ocorrência de falhas para o hardware e software.

Figura 3 – Curva de falhas para o Hardware



Figura 4 – Curva de Falhas para o Software

Podemos observar que a curva de falhas do hardware aumenta de acordo com

o passar do tempo. Já a curva de falhas do sofware, se considerarmos o modelo ide-

al, a tendência é que deixem de ocorrer com o tempo. Porém, como já discutimos nos

itens anteriores, problemas com o gerenciamento e o desenvolvimento do software

podem ocasionar falhas, quando se solicita uma alteração no software que já está

estável (modelo real).

A terceira característica apontada por PRESSMAN sugere que o software seja

sempre desenvolvido do início, ou seja, todos os programas e instruções são escri-

tos novamente a cada software, pois a característica dos softwares, muitas vezes, é

específica. Já com o hardware, componentes podem ser utilizados na sua produção,

reduzindo o tempo de produção e maximizando a qualidade do produto final. Nessa

característica, porém, a produção de software tem evoluído bastante com a utilização

da orientação a objetos, cuja programação torna possível “criar” componentes de sof-

tware que permitam sua reutilização nos próximos projetos de software. Essa é uma

tendência para o desenvolvimento de software.

De acordo com as características acima descritas, podemos interpretar o de-

senvolvimento de software como uma tarefa complexa que pode aumentar, dependen-

do da área de negócio onde o software irá atuar e também do seu tamanho, conforme

a quantidade de funcionalidades que irá dispor.

Assim, para minimizar essa complexidade e auxiliar na definição das funcionali-

dades do software, métodos, como a modelagem de sistemas, surgiram como suporte

para os projetos de software. A utilização de um modelo supre a necessidade de uma



representação idealizada de um software a ser desenvolvido. Por meio dos modelos,

será mais fácil compreender as funcionalidades e objetivo principal do sistema de sof-

tware, além de demonstrar a forma com que será desenvolvido.

Podemos comparar a modelagem de sistemas com a modelagem de outras

áreas da engenharia.

Um engenheiro de construção naval, por exemplo, desenvolve maquetes –

modelos de navios em tamanho reduzido – para representar o formato do navio e

analisar os detalhes da construção final do navio. Ao construir a maquete do navio,

o engenheiro naval poderá identificar vários problemas com o projeto inicial e corrigi-

los ainda nessa fase de modelo. Imagine: se o navio fosse construído direto, sem

que um modelo fosse desenvolvido anteriormente? Provavelmente muitos recursos

seriam disperçados ou, dependendo da grandeza do problema, o projeto poderia ser

inviabilizado.

Da mesma forma acontece com o desenvolvimento de sistemas de software.

Ao construirmos um modelo, temos a oportunidade de analisar com detalhes o funcio-

namento e as necessidades de recursos para o desenvolvimento do software e corri-

gir os possíveis problemas ainda na fase de modelo. Essa prática permitirá maximizar

a garantia de um software com maior qualidade.

1.2 Vantagens da Modelagem de Software

De acordo com BEZERRA (2002, p. 2) existem quatro razões para a utilização

da modelagem no desenvolvimento de software:

1. Gerenciamento da complexidade;

2. Comunicação entre as pessoas envolvidas;

3. Redução dos custos no desenvolvimento;

4. Predição do comportamento futuro do sistema.

Ao utilizar um modelo que simule o funcionamento do software, poderemos

comprender a real complexidade que envolverá o seu desenvolvimento. Com base

nesse conhecimento, será possível definir quais técnicas e procedimentos permitirão

gerenciar e reduzir a complexidade do software. Além disso, com o modelo, será



mais fácil discutir com uma equipe e identificar as melhores práticas e/ou ferramentas

necessárias para o seu desenvolvimento.

Defender uma idéia com um modelo já proposto também se torna muito mais

fácil e simples do que fazê-lo com uma idéia que ainda está no

pensamento. Isso porque, ao criar o modelo, muitas alterações e

melhorias poderão ser identificadas durante a sua construção. Ou

seja, já na criação do modelo, o próprio autor identifica problemas

que poderiam surgir e já faz as correções necessárias para apre-

sentar a idéia concreta aos demais membros da equipe.

A redução do custo, por sua vez, pode ser identificada conforme o tempo gas-

to no desenvolvimento de um software que não foi corretamente definido. Imagine

ir desenvolvendo um projeto apenas de acordo com o que “se acredita” ser a forma

correta. Ao apresentar a versão final do software para o usuário, é bem possível que

as seguintes frases sejam ditas: “Não era bem isso que eu queria” ou “Não foi isso que

eu pedi”. Assim, para evitar esse tipo de constrangimento, tanto para o desenvolvedor

quanto para o usuário, o ideal é construir um modelo dispendendo muito menos tempo

do que o desenvolvimento completo do sistema, e realizar a validação do modelo com

o usuário, antes do início da construção do sistema. Isso garantirá maior sucesso na

entrega do software.

Por fim, a predição do comportamento futuro do sistema pode ser considerada

como a principal razão para a construção do modelo de software, pois, com o modelo,

será possível mapear todo o funcionamento e também a interação entre as funciona-

lidades do software a ser desenvolvido.

1.3 Evolução da Modelagem de Software

A modelagem é uma prática que vem acompanhando a evolução do desenvol-

vimento de software. Por ser uma prática comum em outras engenharias, a modela-

gem também foi absorvida pela engenharia de software para dar suporte e permitir a

análise de detalhes do software, antes mesmo de sua produção.

BEZERRA (2002, p. 12) faz um breve resumo histórico da evolução da mode-

lagem de sistemas:



• Décadas de 1950/1960 – os sistemas de software eram bastante simples. O

desenvolvimento desses sistemas era feito de forma “ad-hoc”. Os sistemas

eram significativamente mais simples e, con-

seqüentemente, as técnicas de modelagem

eram mais simples: era a época dos fluxogra-

mas e dos diagramas de módulos.

• Década de 1970 – computadores mais avançados e acessíveis começaram

a surgir. Houve grande expansão do mercado computacional. Sistemas mais

complexos começavam a surgir. Por conseguinte, modelos mais robustos fo-

ram propostos. Surgem a Programação Estruturada e o Projeto Estruturado.

Os autores Larry Constantine e Edward Yourdon são grandes colaboradores

nessas técnicas.

• Década de 1980 – os computadores se tornaram ainda mais avançados e

baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou

a produção de sistemas de softwares mais complexos. A Análise Estruturada

surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter

Coad, Tom DeMarco, James Martin e Chris Gane.

• Início da década de 1990 – período em que surge um novo paradigma de

modelagem, a Análise Orientada a Objetos. Grandes colaboradores desse pa-

radigma são Sally Shlaer, Stephen Mellor, Rebecca Wirfs-Brock, James Rum-

baugh, Grady Booch e Ivar Jacobson.

• Fim da década de 1990 – o paradigma da orientação a objetos atinge sua

maturidade. Os conceitos de padrões de projeto, frameworks, componentes

e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem

Unificada UML.

2 INTRODUçÃO A UML

A UML (Unified Modeling Language) é uma linguagem-padrão para

a elaboração da estrutura de projetos de software. Pode ser

empregada para a visualização, a especificação, a construção

e a documentação de artefatos que façam uso de sistemas

Este termo significa “direto ao assunto” ou “direto ao que inte-ressa”.



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

A construção da UML teve muitos contribuintes, mas os principais foram: Grady

Booch James Rumbaugh e Ivar Jacobson. Três pesquisadores freqüentemente cha-

mados de “os três amigos” (BEZERRA, 2002, p. 13).

Como vimos no tópico 1.3, sobre a evolução da modelagem de sistemas, du-

rante a década de 1990, vários pesquisadores desenvolveram técnicas de modela-

gem com base na orientação a objetos. Os “três amigos”, que também estavam en-

volvidos em muitas dessas técnicas, procuraram unir as melhores propostas, realizar

melhorias e, por fim, criaram a UML.

Mas foi somente em 1997 que a UML foi aprovada como um padrão pelo órgão

internacional que rege os padrões na área de orientação a objetos, o OMG – Object

Management Group, http://www.omg.org

A partir de então, a UML tem tido grande aceitação pela comunidade de de-

senvolvedores de software. Atualmente, a linguagem está na sua segunda versão

– conhecida como UML 2 -, e continua em constante desenvolvimento. Empresas

como: HP, IBM, Oracle, Microsoft, entre tantas outras, tem dado especial atenção na

divulgação e evolução da linguagem.

2.2 Características da UML

A UML é uma linguagem visual para modelar sistemas orientados a objetos.

Significa que a UML é composta de elementos gráficos – visuais – que podem ser uti-

lizados na modelagem e, permitem representar os conceitos do paradigma da orien-

tação a objetos.

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

• Visualizar;



• Especificar;

• Construir;

• Documentar

os artefatos de um sistema complexo de software.

Por meio dos elementos gráficos da UML, é possível visualizar, de forma mais

detalhada, como será o funcionamento do software e quais serão os objetos necessá-

rios para a construção do sofware.

Assim como a linguagem dispõe de elementos gráficos, que possibilitam me-

lhor visualização do funcionamento do software,

existem também artefatos que permitem detalhar

o funcionamento de forma textual. Existe um ditado

que diz: “Uma figura vale por mil palavras”, porém em alguns casos, pode-se utilizar

uma semântica para interpretar um símbolo UML.

Por ser uma linguagem-padrão, a UML tem sido absorvida por várias ferramen-

tas comerciais para dar suporte e facilitar o trabalho dos desenvolvedores durante a

construção do software. Algumas ferramentas permitem, por meio dos modelos UML,

a geração automática de partes do código-fonte do software. Em alguns casos, até

o inverso também é possível – prática conhecida como engenharia reversa -, onde a

ferramenta poderá gerar o modelo UML por meio de um código- fonte do software. A

prática de engenharia reversa, porém, não é muito aconselhável, pois o ideal é que do

modelo se parta para a construção final, e não o inverso, evitando problemas, alguns

já vistos nos tópicos anteriores, que podem surgir quando o software é construído por

completo sem ter um planejamento ou modelo a ser seguido. Em casos de atualiza-

ção do modelo, por exemplo, a engenharia reversa pode ser uma boa prática a ser

utilizada.

Um artefato é pode ser traduzido como um documento de modela-gem de orientação a objetos.



Fique sabendo

O termo “engenharia reversa” tem suas origens no mundo do hardware. Uma empresa desmonta um hardware comercializado,

num esforço para entender os “segredos” de projeto e manufatura do concorrente. A engenharia reversa para o software é muito semelhante,

porém, na maioria dos casos, o software que irá passar por este processo é da própria empresa e tem como objetivo principal gerar a documentação de partes do código que foram implementadas – muitas vezes direto no código, sem desenvolvimento de um modelo específco. (PRESSMAN, 1995, p. 900)

Com base nos artefatos gerados por meio dos elementos da UML, é possível

também possuir uma documentação a respeito do funcionamento do software.

A UML abrange a documentação da arquitetura do sistema e de todos os seus deta-

lhes proporciona uma linguagem para a expressão de requisitos e para a realização

de testes. Também oferece uma linguagem para a modelagem das atividades de

planejamento do projeto e de gerenciamento de versões.

A UML foi criada especificamente para a área de modelagem de sistemas de

software, porém seus elementos e suas técnicas permitem sua utilização para mo-

delagem de outros projetos sistemas que não de software. Depois de sua aprovação

como um padrão, a linguagem, segundo Booch (2005, p.17), vem sendo empregada

em diversas áreas de conhecimento:

• Sistemas de informações corporativos;

• Serviços bancários e financeiros;

• Telecomunicações;

• Transportes;

• Defesa/espaço aéreo;

• Vendas de varejo;

• Eletrônica médica;

• Científicos;

• Serviços distribuídos baseados na WEB.

A UML é independente tanto de linguagens de programação quanto de proces-

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



mas, não importando qual a linguagem de programação a ser utilizada na implemen-

tação do sistema, ou qual a forma – processo – de desenvolvimento adotado. Esse

é um fator importante para a utilização da UML, pois diferentes sistemas de software

requerem diferentes abordagens de desenvolvimento.

2.3 Visões de um Sistema

Como já dissemos, um sistema de software é algo complexo. Desta forma,

muitas vezes será necessário a criação de mais de um modelo, cada um com o foco

em uma determinada funcionalidade ou detalhe do sistema, para que seja possível

conceber a abrangência do software. Para isso, os autores da UML – os três amigos

– sugerem a utilização das: Visões do Sistema, que podem ser classificadas da se-

guinte forma:

• Visão de Caso de Uso: descreve o sistema de um ponto de vista externo,

como um conjunto de interações entre o sistema e os agentes externos ao

sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das

outras visões do sistema.

• Visão de Projeto: enfatiza as características do sistema que dão suporte,

tanto estrutural quanto comportamental, às funcionalidades externamente visí-

veis do sistema.

• Visão de Implementação: abrange o gerenciamento de versões do sistema

– controle de alterações -, construídas por meio do agrupamento de módulos –

componentes – e subsistemas.

• Visão de Implantação: corresponde à distribuição física do sistema em seus

subsistemas e à conexão entre essas partes.

• Visão de Processo: enfatiza as características de concorrência – paralelis-

mo -, sincronização e desempenho do sistema.

É claro que, dependendo das características do projeto, nem todas as visões

precisarão ser utilizadas. Sua utilização vai depender do tamanho do projeto e da

complexidade. Esta também é uma das grandes vantagens da UML, que permite ser

flexível de acordo com a necessidade de cada projeto. A interação entre as visões é



demonstrada na figura 5.

Figura 5 – Visões de um Sistema de Software

3 A UML E O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Desenvolver software é uma atividade complexa, que pode ser minimizada ou

maximizada, dependendo da área de negócio em que o software irá atuar; do hardwa-

re que irá utilizar; ou ainda, do tipo de procedimento que irá executar.

Vimos na primeira aula, segundo os dados do “Chaos Report”, o resultado das

pesquisas realizadas pelo Standish Group, que grande parte dos projetos de software

são considerados: fracassados – projetos que não são entregues – e comprometidos

– projetos que são entregues porém com os custos, prazos e funcionalidades compro-

metidas.

Portanto, todas as tentativas da engenharia de software que visam minimizar

essa complexidade no planejamento e desenvolvimento dos projetos, envolvem a de-

finição de processos de desenvolvimento de software.

Um processo de desenvolvimento de software – ou simplesmente, processo de

desenvolvimento – compreende todas as atividades necessárias para definir, desen-

volver, testar e manter um produto de software (BEZERRA, 2002, p. 19).

Os principais objetivos do processo de desenvolvimento de software são:

• Definição das atividades que serão executadas ao longo do projeto;

• Definição de quando, como e por quem as atividades serão executadas;

• Definição de pontos de controle para verificar o andamento do desenvolvi-

mento;



• Padronizar a forma de desenvolver software em uma organização.

A UML é uma grande aliada do processo de desenvolvimento. Por ser uma lin-

guagem padrão, permite que várias pessoas, com diferentes habilidades e envolvidas

no processo de desenvolvimento, possam compreender, analisar e sugerir melhorias

para o sistema de software, tudo isso por meio dos modelos definidos.

Veremos mais detalhes sobre o processo de desenvolvimento de software no

capítulo 5.

Síntese da Aula

Nesta aula estudamos,

• A definição de software e como surgiu;

• O que é e qual a importância da modelagem de sistemas de software;

• Os conceitos básicos da UML;

• O que é Processo de Desenvolvimento de Software e como a UML pode con-

tribuir para este processo.


1) Assinale a alternativa incorreta:

a) O software surgiu com o objetivo de auxiliar o hardware nas atividades de manipu-

lação da informação;

b) O software, assim como o hardware, pode ser desenvolvido de forma manufatura-

da;

c) O software é geralmente desenvolvido “sob medida”;

b) O software é um objeto lógico.



2) Assinale a alternativa correta:

a) A curva de falhas do software é considerada pequena no início do desenvolvimento,

porém tende a crescer com o passar do tempo;

b) A curva de falhas do hardware é considerada pequena no início do desenvolvimen-

to, porém tende a crescer com o passar do tempo;

c) A curva de falhas do hardware é considerada grande no início do desenvolvimento,

se estabiliza após a entrega do projeto, porém tende a crescer com o passar do tem-

po;

d) A curva de falhas do software é considerada grande no início do desenvolvimento,

se estabiliza após a entrega do projeto, porém tende a crescer com o passar do tem-

po;

3) Assinale a alternativa incorreta. As vantagens na utilização da modelagem

são:

a) Redução do prazo de desenvolvimento;

b) Gerenciamento da complexidade;

c) Visualização abrangente do funcionamento do sistema;

d) Redução do custo de desenvolvimento;

4) A UML surgiu na década de (única escolha):

a) 1960

b) 1970

c) 1980

d) 1990

5) Assinale a alternativa incorreta. Por meio da UML é possível:

a) Visualizar o funcionamento do sistema de software;

b) Escrever as instruções dos programas que irão compor o sistema de software;

c) Especificar o funcionamento do sistema de software de maneira textual;

d) Construir vários modelos que permitirão interpretar o funcionamento do sistema de

sofware.



Aula 3

INTRODUÇÃO A FERRAMENTA CASE

Nesta aula você estudará sobre os conceitos básicos

que envolvem as ferramentas CASE e quais são os ti-

pos de ferramentas disponíveis para suporte ao desen-

volvimento de projetos de software. Também estudará a ferramenta

CASE que estaremos utilizando na disciplina que possibilitará a

criação de modelos para os projetos de software.

Boa aula!

Objetivos da Aula


• Identificar os principais conceitos da Ferramenta CASE;

• Enumerar os tipos existentes de Ferramenta CASE;

• Instalar a Ferramenta JUDE;

• Visualizar o ambiente de trabalho da Ferramenta JUDE.

Conteúdos da Aula



• Introdução à Ferramenta CASE;

• Utilizando Ferramenta CASE para Análise e Modelagem

de um Projeto;




1 INTRODUçÃO A FERRAMENTAS CASE

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

guês: Engenharia de Software auxiliada por computador. O significado do nome CASE

sugere a seguinte situação: desenvolver sistemas de software, utilizando as práticas

da Engenharia de Software e os recursos disponíveis por meio do computador.

Esses recursos, disponíveis por meio do computador, são classificados como

aplicativos – produtos de software, por exemplo – que foram desenvolvidos especifi-

camente para auxiliar nas tarefas de planejamento e desenvolvimento de projetos de

software.

Existem diversos aplicativos/ferramentas CASE disponíveis no mercado e com

finalidades diversas. Conforme Bezerra (2002, p.39), as principais características das

ferramentas CASE são:

• Criação de diagramas e manutenção da consistência entre os diagramas;

• Geração de código-fonte a partir de diagramas e geração de diagramas a

partir do código-fonte – engenharia reversa;

• Depuração de código-fonte: ferramentas que permitem encontrar erros de

lógica em partes de um programa;

8 Relatórios de testes: ferramentas que geram relatório informando sobre par-

tes de um programa que não foram testadas;

• Testes automáticos: ferramentas que realizam testes automaticamente no sis-

tema;

• Gerenciamento de versões: ferramentas que permitem gerenciar as diversas

versões dos artefatos de software gerados durante o ciclo de vida de um sis-

tema;

• Verificação de desempenho: averiguar o tempo de execução de módulos de

um sistema, assim como o tráfego de dados em sistemas em rede;

• Verificação de erros em tempo de execução;

• Gerenciamento de mudanças nos requisitos.

Além das características citadas por BEZERRA, existem também ferramentas



CASE que auxiliam no gerenciamento dos projetos de software. Esse tipo de ferra-

menta é utilizado pelos gerentes de projeto e permite: desenvolver cronogramas de

tarefas, definição de custos do projeto, acompanhamento de prazos e custos do pro-

jeto, alocação de profissionais para a execução das tarefas previstas no projeto, entre

outras.

1.2 Por que utilizar Ferramentas CASE em projetos de software

As ferramentas CASE surgiram com o objetivo principal de solucionar proble-

mas de qualidade e produtividade no desenvolvimento dos projetos de software. Para

compreendermos melhor essa questão, vamos utilizar a seguinte analogia: “Um me-

cânico possui em sua oficina inúmeras ferramentas em sua caixa de ferramentas que

permitem que seu trabalho seja desempenhado da melhor forma.” Do mesmo modo,

podemos interpretar as ferramentas CASE como ferramentas que podem ser adicio-

nadas à caixa de ferramentas do Engenheiro de Software e que permitirão desenvol-

ver o trabalho de forma mais produtiva. O aumento da produtividade irá, conseqüen-

temente, resultar em aumento da qualidade das atividades.

Outra vantagem que pode ser verificada na utilização das ferramentas CASE

é a melhoria das comunicações e documentações do projeto de software, devido à

maior possibilidade de precisão, consistência e representações claras de um sistema

de software.

A padronização de modelos e atividades também poderá ser adquirida por

meio das ferramentas CASE, porque algumas definições, em relação a metodologias,

técnicas e procedimentos, deverão ser empregadas no processo de desenvolvimento

de software, ao adotar uma ferramenta CASE como suporte no desenvolvimento de

projetos.

Mas a adoção de uma ou um conjunto de ferramentas CASE não é uma tarefa

fácil, devido ao custo – ainda que existam ferramentas gratuitas – e a complexidade

que uma ferramenta dessas pode trazer se o ambiente de trabalho e os profissionais

não estiverem capacitados para sua utilização.

Portanto, é imprescindível, antes da adoção dessas ferramentas, considerar os

seguintes itens:



• Custo de longo prazo da manutenção das ferramentas CASE (potencialmente

ao longo do ciclo de vida do sistema desenvolvido com a ferramenta);

• Lançamento freqüente de nova tecnologia;

• Custos contínuos para treinamento de novos funcionários e atualização dos

funcionários existentes já treinados;

• Reestruturação das ferramentas.

O sucesso ou falha na adoção das ferramentas CASE depende muito da habi-

lidade de uma organização para gerenciar custos de curto e longo prazo. As organi-

zações que têm tido cuidado com esses tipos de problemas no processo de adoção,

apresentam as melhores chances de sucesso.

O SEI - Software Engineering Institute - Instituto de Engenharia de Software

-, desenvolveu um processo de adoção de ferramentas CASE, cujo modelo define

seis estágios:

• Consciência;

• Comprometimento;

• Seleção;

• Implementação de testes;

• Estratégia de implementação;

• Rotinização

Os estágios sugeridos e a forma de aplicação podem ser observados na figura

6.

Figura 6 – Processo sugerido para adoção das ferramentas CA



1.3 Tipos de Ferramentas CASE

A engenharia de sofware auxiliada por computador pode ser tão simples quanto

uma única ferramenta que suporte uma atividade de engenharia de software específi-

ca ou tão complexa quanto um “ambiente” completo que abranja ferramentas, banco

de dados, pessoas, hardware, rede, sistemas operacionais, padrões e uma infinidade

de outros componentes (PRESSMAN, 1995, p. 947).

Um ambiente CASE, como vimos na definição de PRESSMAN, poderá abran-

ger muito mais do que uma única atividade no desenvolvimento de softwares, poderá

abranger todo o processo de desenvolvimento. A figura 7 ilustra a atuação do CASE

dentro de um ambiente integrado.

Figura 7 – Ambiente CASE

As ferramentas CASE podem ser classificadas por função, por seus papéis

como instrumentos para os gerentes e para o pessoal técnico pelo uso que têm nas

várias etapas do processo de engenharia de software, pela arquitetura de ambiente

– hardware e software – que as suporta ou até mesmo pela origem ou custo delas

(PRESSMAN, 1995, p. 951).

As ferramentas CASE podem ser classificadas da seguinte maneira:

• Ferramentas de planejamento de sistemas comerciais;

• Ferramentas de gerenciamento de projetos;

→ Ferramentas de planejamento de projetos;

→ Ferramentas de rastreamento dos requisitos;

→ Ferramentas de métricas e gerenciamento;

• Ferramentas de apoio;

→ Ferramentas de documentação;



→ Ferramentas de software básico;

→ Ferramentas de garantia da qualidade;

→ Ferramentas de banco de dados;

• Ferramentas de Análise e Projeto;

• Ferramentas de Programação;

• Ferramentas de Integração e Teste;

• Ferramentas de Prototipação;

• Ferramentas de Manutenção;

→ Ferramentas de Engenharia Reversa;

→ Ferramentas de Reengenharia;

• Ferramentas de Estrutura.

Nesta disciplina, utilizaremos a ferramenta CASE: JUDE que auxilia na fase de

análise e projeto do sistema de software.

2 UTILIZANDO FERRAMENTA CASE PARA ANÁLISE E PROJETO

As ferramentas de análise e projeto possibilitam que o engenheiro de software

crie um modelo do sistema que será construído (PRESSMAN, 1995, p. 958).

No modelo sugerido por PRESSMAN, será possível demonstrar informações

como: funcionalidades do sistema, componentes que serão utilizados pelas funcio-

nalidades, interação entre o usuário do sistema e as funcionalidades, forma como os

dados gerados pelo sistema serão armazenados, entre outros.

Na verdade, serão criados vários modelos, cada um com uma finalidade espe-

cífica, porém a união destes modelos irá representar o contexto geral e abrangência

do sistema de software que será desenvolvido.

2.1 O que é JUDE?

JUDE – Java and UML Developers’ Environment - é uma ferramenta CASE,

classificada como uma ferramenta de análise e projeto, que permite desenvolver a

modelagem de sistemas orientados a objetos, utilizando a linguagem padrão UML.

Ferramentas de prototipação são ferramentas que permitem ao de-senvolvedor criar um protótipo – modelo – que irá representar o layout das telas do sistema de software.



Atualmente, a ferramenta possui três versões:

1. Community – versão gratuita, basta realizar um cadastro para ter acesso ao

arquivo de instalação;

2. Professional – é uma versão paga, pois disponibiliza mais recursos de inte-

gração com outras ferramentas;

3. Server – também uma versão paga que possui recursos como controle de

versão.

Nesta disciplina utilizaremos a versão Community da ferramenta. É uma versão

gratuita, mas possui todos os recursos necessários para desenvolvimento da mode-

lagem de projetos de software com base nos principais diagramas UML. Na aula 4,

veremos mais detalhes sobre os diagramas UML.

2.2 Instalando a ferramenta JUDE

Antes de iniciar o processo de instalação da ferramenta, será necessário aces-

sar o site e realizar um cadastro. Efetuando o cadastro, será habilitado um link para

acesso ao arquivo de instalação da ferramenta. Após o download do arquivo de ins-

talação, basta executá-lo e seguir as instruções de instalação.

Os passos para o processo de instalação são:

1. Acesse o site:

https://jude.change-vision.com/jude-web/product/community.html;

2. Clique no botão: [Download Jude Members Login], conforme mostra a figura 8;

Figura 8 – Site da ferramenta JUDE



3. Na tela seguinte, conforme mostra a figura 9, clique no botão: [New Registration]

para realizar o seu cadastro;

Figura 9 – Tela de acesso ao cadastro

4. Na próxima tela será solicitada a leitura do termo de contrato e o aceite dos termos

do contrato. Para dar continuidade, clique no botão: [I agree];

5. Em seguida, será mostrada a tela de cadastro (figura 10). Preencha todos os cam-

pos obrigatórios com atenção e, ao final, clique no botão para confirmação do cadas-

tro, botão: [Confirm];

Figura 10 – Tela de cadastro

6. Ao clicar no botão de confirmação, será mostrada uma tela para que você possa

validar os dados informados. Se os dados estiverem corretos, clique no botão: [Re-



gister] para efetivar o cadastro;

7. A confirmação do cadastro será encaminhada para o e-mail informado na tela de

cadastro. Para ter acesso ao arquivo de instalação da ferramenta, clique no botão:

[OK] da tela de confirmação de cadastro e informe o login e senha cadastrados;

8. Na tela seguinte, após a autenticação do seu login e senha, clique no botão: [Down-

load], conforme mostra a figura 11;

Figura 11 – Tela de acesso dos membros JUDE

9. Na próxima tela, serão disponibilizadas todas as versões do JUDE para download.

As versões pagas – Professional e Server – irão exigir o preenchimento da licença

após a instalação. Portanto, a versão que utilizaremos é a Community. Como o

JUDE é uma ferramenta desenvolvida em Java, é necessário que você possua em

seu computador a máquina virtual Java instalada, caso contrário, você poderá pegar

o arquivo de instalação do JUDE que vem com a máquina virtual embutida;

10. Se você já possui a máquina virtual Java instalada em seu computador, faça do-

wnload do primeiro arquivo listado na figura 12. Caso contrário, se você não possui a

máquina virtual Java instalada, faça o download do segundo arquivo da figura 12;



Figura 12 – Tela de acesso dos membros JUDE

11. Na próxima tela, clique no botão: [Download] para iniciar o processo de transferên-

cia do arquivo de instalação;

12. Finalização o download, clique duas vezes em cima do arquivo: jude-community-

5_2b1-setup.exe para iniciar a instalação. Selecione o idioma inglês e clique no bo-

tão: [Next], conforme mostra a figura 13;

Figura 13 – Tela 1 da instalação da ferramenta

13. Na tela seguinte, clique no botão: [Next], conforme mostra a figura 14;


Arquivo 1

Arquivo 1



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

clique no botão: [Next], conforme mostra a figura 15;


15. Na tela seguinte, será solicitado o local para a instalação da ferramenta. Se prefe-

rir, deixe o local sugerido e clique no botão: [Next], conforme mostra a figura 16;


16. A próxima seguinte mostra o nome que será incluído no menu iniciar. Deixe o pa-

drão e clique no botão: [Next], conforme indica a figura 17;




17. A próxima tela seguinte questiona se você deseja: (1) incluir um ícone da ferra-

menta no desktop, (2) incluir um ícone no Quick Launch – acesso rápido -, (3) associar

os arquivos com extensão: .jude com a ferramenta. Deixe o padrão e clique no botão:

[Next], conforme mostra a figura 18;


18. Conforme mostra a figura 19, a próxima tela mostrará as informações seleciona-

das até agora. Valide as informações e clique no botão: [Install] para iniciar a instala-

ção da ferramenta.


19. A instalação será iniciada conforme mostra a figura 20. Aguarde até o final da

instalação.




20. Finalizada a instalação, será mostrada a tela conforme a figura 21. Clique no bo-

tão: [Finish] e a ferramenta JUDE será inicializada.


21. O ambiente de trabalho da ferramenta JUDE pode ser visualizado na figura 22.

Nas próximas aulas, veremos mais detalhes sobre a utilização da ferramenta.

Figura 22 – Área de trabalho da ferramenta JUDE



Síntese da Aula


• Os conceitos básicos sobre ferramentas CASE;

• Os tipos de ferramentas CASE existentes;

• O que é JUDE;

• Os passos para a instalação da ferramenta JUDE.


1) Assinale a alternativa incorreta. É característica das ferramentas CASE:

a) Definição das atividades do projeto;

b) Depuração do código-fonte;

c) Criação e manutenção de diagramas;

d) Realização de testes automáticos.

2) O principal objetivo das ferramentas CASE é (apenas uma alternativa está

correta):

a) Auxiliar na geração do código-fonte;

b) Aumentar a produtividade;

c) Solucionar os problemas de qualidade e produtividade;

d) Auxiliar na definição das tarefas.

3) Assinale a alternativa incorreta, antes de adotar um conjunto ou uma única

ferramenta CASE é aconselhável observar:

a) A linguagem de programação que é utilizada;

b) O custo da ferramenta CASE;



c) Os recursos disponibilizados pela ferramenta CASE;

d) O ambiente para a integração da ferramenta CASE.

4) O JUDE é uma ferramenta CASE classificada como (apenas uma alternativa

está correta):

a) Ferramenta para gerenciamento de projetos;

b) Ferramenta para apoio;

c) Ferramenta para análise e projeto;

d) Ferramenta para programação.



Aula 4

CONHECENDO OS PRINCIPAIS DIAGRAMAS UML

Nesta quarta aula, vamos estudar quais são os ele-

mentos da UML e os principais diagramas utilizados

na modelagem de sistemas de software. Além disso,

veremos também a função de cada diagrama e sua representação

na modelagem de um sistema

de software.

Bom estudo!

Objetivos da Aula


• Enumerar os elementos da UML;

• Identificar os principais diagramas UML;

• Descrever o objetivo de cada diagrama.

Conteúdos da Aula



• Elementos da UML;

• Diagramas UML;




1 ELEMENTOS DA UML

Antes de introduzirmos os conceitos dos elementos da UML e seus principais

diagramas, é importante lembrar que a UML é baseada nos conceitos da orientação

a objetos, portanto, para melhor entendimento deste e dos próximos capítulos, é

imprescindível possuir o conhecimento básico do paradigma da orientação a objetos.

No apêndice 1 (final deste livro) está disponível um resumo com os principais concei-

tos da Orientação a Objetos.

A UML é composta dos seguintes elementos:

• Itens;

• Relacionamentos;

• Diagramas.

Os itens são os elementos utilizados nos diagramas para ilustrar com detalhes

o objetivo de um modelo. Os relacionamentos são, como o próprio nome sugere, os

relacionamentos entre os itens de um modelo e os diagramas, por sua vez, são os

elementos que agrupam e permitem a visualização dos itens e seus relacionamentos.

Um modelo de sistema de software pode conter um ou mais diagramas UML.

Os itens são classificados da seguinte forma:

• Itens estruturais;

• Itens comportamentais;

• Itens de agrupamentos;

• Itens anotacionais.

Os itens estruturais são considerados a parte estática dos modelos da UML.

São exemplos de itens estruturais:

• Classes – são descrições de conjuntos de objetos que compartilham os mes-

mos atributos, operações, relacionamentos e semântica;

• Interfaces – é uma coleção de operações que especificam serviços de uma

classe ou componente;

• Casos de Uso – descrição de seqüências de ações realizadas pelo sistema



que proporciona valor para um determinado ator.

Os itens comportamentais são considerados a parte dinâmica dos modelos

da UML. Representam comportamentos no tempo e no espaço. São exemplos de

itens comportamentais:

• Mensagens – mostram as interações entre os objetos, classes;

• Estados – definem os comportamentos que os objetos e classes podem as-

sumir ao longo do sistema;

• Ações – são as ações desempenhadas pelos objetos e classes do sistema.

Os itens de agrupamento são as partes organizacionais dos modelos UML.

Existe apenas um tipo principal de itens de agrupamento, os pacotes. Um pacote é

um mecanismo que permite a organização dos itens estruturais e comportamentais.

Por fim, os itens anotacionais são as partes explicativas dos modelos da UML. São

os comentários incluídos nos modelos e que permitem descrever, esclarecer e/ou

fazer alguma observação sobre qualquer elemento utilizado no modelo. A tabela 1

ilustra os elementos gráficos que representam os itens da UML.

Tabela 1 – Itens da UMLClassificação do Item Nome Figura

Estrutural Classe

Estrutural Interface

Ou



Estrutural Caso de Uso

Comportamental Mensagens

Comportamental Estados

Comportamental Ações / Atividades

Agrupamento Pacotes

Anotacional Notas

2 DIAGRAMAS UML

Um diagrama é apresentação gráfica de um conjunto de elementos da UML: os

itens e relacionamentos. Os diagramas são desenhados para permitir a visualização

de um sistema sob diferentes perspectivas ou visões do sistema. Retorne à aula 2

(figura 5) para observar as visões do sistema.

O diagrama UML irá representar uma visão parcial, em outras palavras, o mo-

delo dos elementos que compõe o sistema. Para cada sistema poderá ser desenhado

um ou mais diagramas. A quantidade de diagramas e a escolha pelo diagrama que

será utilizado vai sempre depender da área de atuação do sistema e da complexidade

do negócio. Um mesmo elemento UML, porém, poderá ser compartilhado em mais de

um diagrama, possibilitando melhor integração entre os modelos.

Atualmente, na versão dois, a UML disponibiliza treze diagramas que permitem

realizar qualquer tipo de combinação de itens e relacionamentos, além de possibilitar



a criação de diversas visões como modelo para os projetos de software. Não é neces-

sário utilizar os treze diagramas para todos os projetos de software desenvolvidos, a

premissa da escolha pelo diagrama e pelo nível de detalhamento dos modelos deve

partir da complexidade do software a ser construído. Quanto maior a complexidade,

maior deve ser o nível de detalhamento dos modelos.

Os treze diagramas da UML 2 são:

1. Diagrama de classes;

2. Diagrama de objetos;

3. Diagrama de componentes;

4. Diagrama de estruturas compostas;

5. Diagrama de casos de uso;

6. Diagrama de seqüências;

7. Diagrama de comunicações;

8. Diagrama de gráfico de estados;

9. Diagrama de atividades;

10. Diagrama de implantação;

11. Diagrama de pacote;

12. Diagrama de temporização;

13. Diagrama de visão geral da interação.

Nesta disciplina estudaremos apenas os principais diagramas UML, são eles:

1. Diagrama de classes;

2. Diagrama de casos de uso;

3. Diagrama de seqüências;

4. Diagrama de gráfico de estados;

5. Diagrama de atividades.

2.2 Diagrama de classes

Os diagramas de classes são os diagramas encontrados com maior freqüência

na modelagem de sistemas orientados a objetos. Um diagrama de classes mostra um

conjunto de classes, interfaces e colaborações, além de seus relacionamentos.



Os diagramas de classes são compostos pelos seguintes elementos:

• Classes;

• Interfaces;

• Relacionamentos.

Esses são os elementos básicos para a composição de um diagrama de clas-

ses, porém, assim como nos demais diagramas, poderá conter: notas – itens anota-

cionais -, e também pacotes – itens de agrupamento.

Uma classe é a descrição de um conjunto de objetos que compartilham os mesmos

atributos, operações e relacionamentos.

A classe é utilizada em um diagrama de classes principalmente para classificar

os objetos identificados no universo do sistema - mundo real onde o sistema irá atu-

ar.

Exemplo de classes para um sistema de loja: cliente, pedido, produto, etc. Em

UML as classes são representadas por um retângulo dividido em três compartimentos:

nome da classe, atributos e operações. A figura 23 ilustra o formato de uma classe.

Figura 23 – Formato de uma classe

Os relacionamentos exibidos em um diagrama de classes têm como objetivo

ligar as classes e interfaces entre si, criando relações entre essas entidades. O rela-

cionamento é representado como um caminho, em que cada relacionamento possui

linhas diferentes, para melhor visualização. Há três tipos de relacionamentos na UML.

A tabela 2 demonstra quais são os tipos de relacionamentos existentes, a função de

cada relacionamento e seu elemento gráfico de representação.



Tabela 2 – Tipos de Relacionamentos

Nome Função Representação

Dependência

Relacionamento entre dois itens, a alteração no item independente pode afetar a semântica – funcio-namento – do item dependente.

Elemento gráfico: seta aberta tracejada Exem-plo:

Notação:• A classe Dependente depende estruturalmente da classe Independente.

Associação

Relacionamento estrutural entre classes que descrevem um con-junto de ligações, em que as liga-ções são conexões entre objetos que são instâncias das classes. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes.

Elemento gráfico: linha simplesExemplo:

Notação:• Um departamento possui um ou mais funcioná-rios na sua hierarquia.

Genera l i za -ção

Relacionamento de um elemento mais geral e outro mais especí-fico. Os objetos da classe-filha podem ser utilizados em qualquer lugar onde a classe-mãe ocorra, mas não o contrário.

Elemento gráfico: seta fechadaExemplo:

Notação:• A classe: Atleta é a classe-mãe.• As classes: Nadador e Tenista herdam a estru-tura – atributos e operações – da classe Atleta.

Classes Asso-ciativas

São classes ligadas a associa-ções, em vez de estarem liga-das a outras classes. Esse tipo de classe normalmente aparece quando duas ou mais classes estão associadas e é necessário manter informações sobre asso-ciação.

Elemento gráfico: classe ligada a uma associa-ção por uma linha tracejadaExemplo:

Classe associativa = Emprego



Os relacionamentos do tipo: Associação possuem ainda algumas caracterís-

ticas que permitem um detalhamento maior no relacionamento entre duas classes.

Estas características estão descritas na tabela 3.

Tabela 3 – Características da AssociaçãoCaracterís-

ticaFunção Representação

Nome

Uma associação pode ter um nome, que pode ser utilizado para descrever a natureza do relacio-namento.

PapelQuando uma classe está em uma associação, possui um papel es-pecífico neste relacionamento.

Multiplicidade

É importante determinar a quan-tidade (multiplicidade) de objetos que podem ser conectados pela instância de uma conexão. A ta-bela 4 ilustra a simbologia para re-presentar as multiplicidades.

Agregação

É um tipo especial de associação que ilustra a associação todo/par-te. Toda ação realizada sobre a classe todo afetará as classes partes.

Composição

A composição é um tipo especial de agregação - agregação por va-lor. Semanticamente equivalente a um atributo.A remoção do todo implica na re-moção das partes e o acesso às partes é restrito ao todo. Significa que as classes/objetos indicadas como “partes” de uma composi-ção não estarão acessíveis ex-ternamente, somente por meio da classe/objeto “todo”.

Classe Pessoa

Classe Pessoa depois de utilizar composição



Tabela 4 – Simbologia para representar multiplicidadesNome Simbologia

Apenas um 1

Zero ou Muitos 0..*

Um ou Muitos 1..*

Zero ou um 0..1

Os diagramas de classes são utilizados para

fazer a modelagem da visão estática de um sis-

tema. Essa visão oferece principalmente suporte

para os requisitos funcionais de um sistema – os

serviços que o sistema deverá fornecer aos usuários finais (BOOCH, 2005, p. 109).

As principais características dos diagramas de classes são:

• Representar os dados e funções tratados pelo sistema;

• Representar a forma como os dados serão armazenados de acordo com a

orientação a objetos – classes e objetos;

A figura 24 ilustra um exemplo de diagrama de classes de um sistema.

Figura 24 – Exemplo de diagrama de classes

Os requisitos funcionais e não-funcionais serão discutidos com mais detalhes nos capítulos 5 e 6.



2.3 Diagrama de casos de uso

Por meio do diagrama de casos de uso, é possível modelar os aspectos dinâ-

micos de um sistema de software. Os diagramas de caso de uso têm um papel im-

portante na modelagem do comportamento de um sistema, por meio dele é possível

identificar de forma visual as funcionalidades do sistema e a interação destas funcio-

nalidades com o usuário final.

Por utilizar uma representação gráfica simples e uma linguagem natural, o dia-

grama de casos de uso facilita a comunicação entre desenvolvedores e usuários. É

um diagrama bem importante, pois direciona as tarefas posteriores do ciclo de vida do

sistema de software.

Os diagramas de caso de uso são compostos pelos seguintes elementos da

UML:

• Fronteira do Sistema ou Assunto;

• Casos de Uso;

• Atores;

• Relacionamentos.

Assim como nos demais diagramas UML, o diagrama de casos de uso também

pode conter elementos como: notas e pacotes.

A fronteira do sistema ou assunto é exibido como um retângulo que agrupa os

casos de uso e seus relacionamentos com os atores e demais casos de uso.

Um caso de uso é a especificação de uma seqüência de interações entre o sis-

tema e os agentes externos que utilizam o sistema. Um caso de uso deve definir o uso

de uma parte da funcionalidade do sistema, sem a necessidade de revelar a estrutura

e o comportamento interno desse sistema.

O caso de uso pode ser representado graficamente em um diagrama de casos

de uso, ou então, detalhadamente em um formato textual. A UML não define o formato

e o grau de abstração a serem utilizados na descrição de um caso de uso, porém exis-

tem alguns modelos que já estão popularizados entre a comunidade UML. A tabela 5

demonstra um dos modelos utilizados para a definição textual dos casos de uso de um

sistema.



Tabela 5 – Documentação de Caso de Uso Caso de Uso: Visualizar Avaliações

Sumário:Aluno visualiza avaliação que recebeu – notas e freqüência – nas turmas de um semestre letivo.

Ator Primário: Aluno

Ator Secundário: Professor

Pré-Condições: O aluno está identificado pelo sistema.

Fluxo Principal:

1. O aluno solicita a visualização das avaliações para as disciplinas em que participou.2. O sistema exibe os semestres letivos nos quais o aluno se inscreveu em pelo menos uma disciplina.3. O aluno seleciona os semestres letivos cujas avaliações deseja visu-alizar.4. O sistema exibe uma lista de avaliações agrupadas por semestres letivos selecionados e por turma.5. O aluno visualiza as avaliações e o caso de uso termina.

Fluxo de Exceção (2):

Aluno sem inscrição1. Não há semestre letivo no qual o aluno tenha participado em alguma disciplina.2. O sistema reporta o fato e o caso de uso termina.

Pós-Condições: O aluno obteve as avaliações que desejava visualizar.

Fonte: BEZERRA, 2002, p. 82

A tabela 5 ilustra, de maneira geral, um modelo que pode ser utilizado para

a documentação de casos de uso, mas como a UML não define um formato para

a documentação textual, é importante conhecer a função de cada item utilizado na

documentação exemplo e definir quais são os itens utilizados em seus projetos de

software.

A função de cada item, segundo Bezerra (2002, p. 66), pode ser identificada do

seguinte modo:

• Nome – é o nome do caso de uso. Cada caso de uso deve possuir um nome

único que também deverá aparecer no diagrama de casos de uso.

• Sumário – uma pequena descrição do caso de uso, funcionalidade. Deve ser

breve e possuir no máximo duas frases.

• Ator Primário – o nome do ator que inicia o caso de uso.

• Ator Secundário – os nomes dos demais atores participantes do caso de

uso, se existirem.

• Pré-Condições – define as hipóteses que são assumidas como verdadeiras



para que o caso de uso tenha início.

• Fluxo Principal – corresponde à descrição da seqüência de passos do fluxo

principal do caso de uso, funcionalidade.

• Fluxos Alternativos – podem ser utilizados para descrever o que acontece

quando o ator faz uma escolha alternativa, diferente da descrita no fluxo prin-

cipal, para alcançar o seu objetivo. Esses fluxos podem ser utlizados também

para descrever situações de escolha exclusivas entre si – em que há diversas

alternativas e somente uma deve ser realizada.

• Fluxos de Exceção – correspondem à descrição das situações de exceção,

que descrevem o que acontece quando algo inesperado ocorre na interação

entre ator e caso de uso – por exemplo, quando um usuário realiza alguma

ação inválida.

• Pós-Condições – descreve o estado que o sistema alcança após o caso de

uso ter sido realizado com sucesso.

Os atores podem ser considerados como qualquer elemento externo que inte-

rage com o sistema. O termo “externo” indica que atores não fazem parte do sistema.

E o termo “interage” significa que um ator troca - envia e/ou recebe - informações com

o sistema.

Os atores podem ser classificados da seguinte forma:

• Pessoas – Empregado, Cliente, Gerente, Almoxarife, Vendedor, etc.;

• Organizações – Empresa Fornecedora, Agência de Impostos, Administrado-

ra de Cartões, etc.;

• Outros Sistemas – Sistema de Cobrança, Sistema de Estoque de Produtos,

etc.

• Equipamentos – Leitor de Código de Barras, Sensor, etc.

Cada ator representa um papel em relação ao sistema. Um ator pode participar

de muitos casos de uso e um caso de uso também pode envolver vários atores: primá-

rios e secundários. O ator primário é aquele que inicia uma seqüência de interações

de um caso de uso; o secundário é aquele que supervisiona, opera, mantém ou auxilia

na utilização do sistema.



A comunicação ou interação entre as funcionalidades do sistema – casos de

uso – e os usuários do sistema – atores – é feita por meio dos relacionamentos. Os

tipos de relacionamentos disponíveis para os diagramas de caso de uso são:

• Comunicação – mais comumente utilizado. Faz a troca de informações entre

o ator e o caso de uso.

• Inclusão – disponível somente entre casos de uso. Utilizado quando dois ou

mais casos de uso incluem uma seqüência comum de interações.

• Extensão – é utilizado para modelar situações em que diferentes seqüências

de interações podem ser inseridas em um caso de uso. Cada uma dessas se-

qüências diferentes representa um comportamento opcional, que só ocorre sob

certas condições ou dependendo da escolha do ator.

• Generalização – é o mesmo conceito utilizado para as classes. Permite que

um caso de uso (ou um ator) herde características de um caso de uso (ou ator)

mais genérico.

A tabela 6 ilustra os elementos gráficos utilizados em um diagrama de casos de

uso.

Tabela 6 – Elementos gráficos do diagrama de casos de usoNome Representação

Fronteira do Sistema

Elemento gráfico: retângulo que agrupa os ca-sos de uso e os relacionamentos

Ator

Elemento gráfico: boneco palito

Caso de Uso

Elemento gráfico: elipse



Relacionamento de Comunicação

Elemento gráfico: linha simples

Relacionamento de Inclusão – somente entre ca-sos de uso

Elemento gráfico: seta tracejada com estereóti-po: <<include>>

Relacionamento de Extensão – somente entre casos de uso

Elemento gráfico: seta tracejada com estereóti-po: <<extend>>

Relacionamento de Generalização

Elemento gráfico: seta fechada

A figura 25 ilustra um exemplo de diagrama de casos de uso.

Figura 25 – Diagrama de Casos de Uso



2.4 Diagrama de seqüência

O diagrama de seqüência faz parte dos diagramas da UML classificados como

diagramas de interação. Os diagramas de interação representam como o sistema age

internamente – comportamento dos objetos, troca de mensagens entre os objetos –

para que um ator atinja seu objetivo na realização de um caso de uso. A modelagem

de um sistema de software geralmente contém diversos diagramas de interação.

O diagrama de seqüência dá ênfase na ordem temporal das mensagens tro-

cadas entre os objetos do sistema de software. Sua função é ilustrar a seqüência do

envio das mensagens entre os objetos no decorrer do tempo.

Assim como os outros diagramas da UML, o diagrama de seqüência possui

um conjunto de elementos gráficos. A figura 26 ilustra um exemplo de diagrama de

seqüência e os seus elementos gráficos.

Figura 26 – Exemplo de diagrama de seqüência

De acordo com a figura 26, podemos verificar que o diagrama de seqüência,

assim como os demais diagramas, compartilham elementos gráficos. No caso do

diagrama de seqüência os elementos que podem ser compartilhados entre os demais

diagramas são: atores, objetos e classes.

Os elementos gráficos que são específicos deste diagrama são:

• Focos de controle – representa o tempo em que o objeto realiza uma ação.

O topo do foco de controle coincide com o recebimento de uma mensagem e

a parte de baixo coincide com a finalização de uma operação realizada pelo



objeto em questão;

• Linha da vida – representa a vida do objeto;

• Mensagem – é a troca de informação entre os objetos. Por meio de uma

mensagem, um objeto faz a chamada da operação de outro objeto.

2.5 Diagrama de gráfico de estados

Os diagramas de interação permitem modelar o funcionamento interno de um

sistema, detalhando a interação dos objetos – troca de mensagens – e a realização

das operações no decorrer do tempo. O diagrama de gráfico de estados, por sua vez,

tem como objetivo demonstrar o funcionamento interno de apenas um objeto. Nesse

diagrama é possível ilustrar as ações que um objeto pode sofrer durante o seu período

de vida no sistema e quais os estados que irá assumir após a realização de cada uma

dessas ações.

Um estado pode ser interpretado como uma situação na vida de um objeto du-

rante a qual ele satisfaz alguma condição ou realiza alguma atividade. Cada estado

de um objeto é normalmente determinado pelos valores dos seus atributos e/ou pelas

suas ligações com outros objetos. Exemplos: (1) o atributo reservado deste objeto

livro tem valor verdadeiro; (2) uma conta bancária passa para o vermelho quando o

seu saldo – atributo do objeto conta bancária – fica negativo.

A figura 27 ilustra um exemplo de diagrama de estados para o objeto Conta-

Bancaria.

Figura 27 – Exemplo de diagrama de estados



Os elementos gráficos do diagrama de estados estão ilustrados na tabela 7.

Tabela 7 – Elementos gráficos do diagrama de estadosNome Representação

Estado inicial do objetoElemento gráfico: círculo preenchido

Estado final do objetoElemento gráfico: círculo elipsado

Estado do objeto

Elemento gráfico: retângulo arredondado

Eventos / Ações – um evento é algo que aconte-ce em algum ponto do tempo e pode modificar o estado do objeto. Uma ação é uma operação que pode ser realizada pelo próprio objeto.

Elemento gráfico: seta

2.6 Diagrama de atividades

Um diagrama de atividade é essencialmente um gráfixo de fluxo, que exibe o

fluxo de controle de uma atividade para outra. Ao contrário de um gráfico de fluxo

tradicional, um diagrama de atividades mostra a concorrência, bem como as ramifica-

ções de controle.

Os diagramas de atividade são utilizados para fazer a modelagem de aspectos

dinâmicos do sistema que envolve a modelagem das etapas seqüenciais – e possivel-

mente concorrentes – em um processo do sistema de software.

O diagrama de atividades irá representar os estados de uma atividade do sis-

tema de software em formato de fluxo de dados.

A figura 28 ilustra um exemplo de diagrama de atividade.



Figura 28 – Exemplo de diagrama de atividades

Os elementos gráficos do diagrama de estados estão ilustrados na tabela 8.

Tabela 8 – Elementos gráficos do diagrama de atividadesNome Representação

Estado inicial da atividadeElemento gráfico: círculo preenchido

Estado final da atividadeElemento gráfico: círculo elipsado

Atores envolvidos na atividade

Elemento gráfico: raias de natação

Ação dos atores nas atividadesElemento gráfico: retângulo arredondado



Decisão

Elemento gráfico: losango

Transição das Ações Elemento gráfico: seta

Síntese da Aula


1) A classificação dos elementos da UML;

2) Os diagramas da UML 2;

3) Os principais diagramas UML utilizados na modelagem de sistemas de sof-

tware;

4) As características, objetivos e representação de cada um destes diagra-

mas.


1) Complete a frase com uma das alternativas abaixo: As classes são elementos

classificados como ..................... da UML.

a) Itens estruturais

b) Itens comportamentais

c) Itens de agrupamento

d) Itens anotacionais



2) O diagrama UML que representa o funcionamento interno de um sistema de

software é:

a) Diagrama de Classes

b) Diagrama de Casos de Uso

c) Diagrama de Atividades

d) Diagrama de Seqüência

3) Assinale a alternativa incorreta. O ator é um elemento que pode ser comparti-

lhado entre os seguintes diagramas:

a) Diagrama de Seqüência

b) Diagrama de Estados

c) Diagrama de Atividades

d) Diagrama de Casos de Uso

4) O relacionamento de comunicação é um relacionamento exclusivo do diagra-

ma de:

a) Classes

b) Casos de Uso

c) Atividades

d) Seqüência



Aula 5

CONHECENDO O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Nesta quinta aula você estudará os conceitos básicos

sobre o processo de desenvolvimento de software;

analisará o que é um processo de desenvolvimento de

software,quais as atividades desempenhadas no processo, quais

os padrões existentes e, por fim, alguns dos principais modelos de

processos disponíveis.

Bons Estudos!

Objetivos da Aula


• Identificar os conceitos básicos do processo de desenvol-

vimento de software;

• Enumerar as atividades do processo;

• Descrever os padrões de processo existentes;

• Analisar os modelos de processo disponíveis.

Conteúdos da Aula



• Introdução ao Processo de Desenvolvimento de Software;

• Conhecendo os Modelos do Processo;

• Exercícios Propostos.



1 INTRODUçÃO AO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Um Processo de desenvolvimento de software pode ser considerado como um con-

junto de atividades que têm como resultado final um produto de software.

Esse conceito é um dos itens estudados pela Engenharia de Software e é um

dos principais mecanismos que permite alcançar as características de sucesso para

os projetos de software: cumprimento de prazo, custo, planejamento e qualidade no

resultado final.

O processo de desenvolvimento de software surgiu com o objetivo de resolver a

chamada: “Crise de Software”.

Fique sabendo

A crise do software foi um termo utilizado nos anos 70, quando a engenharia de software era praticamente inexistente. O termo

expressava as dificuldades do desenvolvimento de software frente ao rápido crescimento da demanda por software, da complexidade dos

problemas a serem resolvidos e da inexistência de técnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou pudessem ser validados.

As causas da crise do software estão ligadas à complexidade do processo de software e à relativa imaturidade da engenharia de software como profissão. A crise se manifesta de várias formas:

• Projetos estourando o orçamento;

• Projetos estourando o prazo;

• Software de baixa qualidade;

• Software muitas vezes não atingia os requisitos;

• Projetos ingerenciáveis e o código difícil de manter;

A maior parte dos projetos continua com esses problemas ainda na atualidade, então pode-se dizer que a crise continua vigente ainda na atualidade.



1.2 Atividades do Processo

O processo de desenvolvimento de software pode ser dividido em sete ativida-

des:

1. Análise de requisitos de software – a extração dos requisitos de um dese-

jado produto de software é a primeira tarefa na sua criação. Embora o cliente,

provavelmente, acredite saber o que o software deva fazer, essa tarefa requer

habilidade e experiência em engenharia de software para reconhecer os requi-

sitos em um sistema de software complexo.

2. Especificação – a especificação é a tarefa de descrever precisamente o

software que será desenvolvido. Nessa atividade será elaborada grande parte

dos diagramas UML.

3. Arquitetura de Software – a arquitetura de um sistema de software faz uma

representação abstrata do sistema. Por meio das tarefas realizadas nessa ati-

vidade, será possível identificar se o sistema de software a ser desenvolvido

está de acordo com os requisitos pré-definidos. A etapa da arquitetura também

direciona as interfaces entre os sistemas de software e outros produtos de sof-

tware, como também com o hardware básico ou com o sistema operacional.

4. Implementação (ou codificação) – é a atividade responsável pelo desen-

volvimento do projeto do software efetivamente. É nessa atividade que o sof-

tware começará a ser construído e codificado por meio de linguagens de pro-

gramação e outras tecnologias pré-definidas nas atividades de Especificação

e Arquitetura de Software.

5. Teste – atividade que desenvolve os testes das funcionalidades do software.

Os testes serão sempre baseados nos artefatos e modelos resultantes das ati-

vidade de Especificação e Arquitetura de Software. Caso uma funcionalidade

não esteja de acordo com sua definição, deverá ser reescrita. Existem vários

métodos que auxiliam no controle do desenvolvimento e testes das funcionali-

dades.

6. Documentação – atividade que se refere à documentação do projeto inter-

no do software para propósitos de futuras manutenções e aprimoramentos. As

documentações mais importantes são das interfaces externas. Grande parte



dessa documentação já foi gerada nas atividades anteriores, principalmente

nas atividades de Especificação e de Arquitetura de Software. A atividade de

Implementação também deve incorporar tarefas de documentação, principal-

mente para descrever e/ou detalhar as instruções que são utilizadas para im-

plementar as funcionalidades do sistema.

7. Suporte e Treinamento de Software – uma grande porcentagem dos pro-

jetos de software falha pelo fato de o desenvolvedor não perceber que não

importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar

na criação do software se ninguém da organização irá usá-lo. As pessoas,

ocasionalmente, resistem à mudança e evitam aventurar-se em áreas pouco

familiares. Então, como parte da fase de desenvolvimento, é muito importante

o treinamento para os usuários de software mais entusiasmados, alternando

o treinamento entre usuários neutros e usuários favoráveis ao software. Os

usuários, freqüentemente, terão muitas questões e problemas de software que

permitirão conduzir o desenvolvimento da próxima fase.

8. Manutenção – a manutenção e melhoria de software lidam com a desco-

berta de novos problemas e requisitos. Pode tomar mais tempo que o gasto no

desenvolvimento inicial. Não somente pode ser necessário adicionar códigos

que combinem com o projeto original, mas determinar como o software traba-

lhará em algum ponto depois da manutenção estar completa, pode requerer

um significativo esforço por parte de um engenheiro de software. Cerca de ⅔

de todos os engenheiros de software trabalham com a manutenção, mas essas

estatísticas podem estar enganadas, pois uma pequena parte desles trabalha

na correção de erros. A maioria das manutenções é para ampliar os sistemas

para novas funcionalidades, as quais, de diversas formas, podem ser conside-

radas um novo trabalho.

A figura 29 ilustra as atividades do processo de desenvolvimento de software e

a interação entre elas.



Figura 29 – Atividades do Processo de Desenvolvimento de Software

1.3 Padrões do Processo

O processo de desenvolvimento de software tem sido objetivo de vários pa-

drões, que visam à certificação das empresas como possuidoras de um processo de

desenvolvimento. Em alguns casos, possuir uma certificação de padrão de processo

de desenvolver pode gerar certo grau de confiança aos contratantes.

Alguns padrões existentes atualmente são:

• CMMI – Capability Maturity Model Integration – é um modelo de referência

que contém práticas necessárias à maturidade em disciplinas específicas como:

Engenharia de Sistemas, Engenharia de Software, Integração de Produtos e

Desenvolvimento de Sof (Systems Engineering (SE), Software Engineering

(SE), Integrated Product and Process Development (IPPD), Supplier Sourcing

(SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade

Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um

modelo único para o processo de melhoria corporativo, integrando diferentes

modelos e disciplinas.

• ISO 12207 – é uma norma definida pela International Organization for Stan-

dardization, que se aplica à Engenharia de Software. Essa norma estabelece

um processo de ciclo de vida do software, contendo processos e atividades

aplicadas durante a aquisição e configuração dos serviços do sistema, de for-

ma a melhorá-los. Seu principal objetivo é fornecer uma estrutura comum para

que os envolvidos com o desenvolvimento de software, utilizem uma lingua-

gem comum.

• SPICE – a ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/



IEC que define um processo de desenvolvimento de software. É uma evolução

da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim

como o CMMI.

• MPS/Br – o MPS.BR ou Melhoria de Processos do Software Brasileiro, é um

modelo de qualidade de processo voltada para a realidade do mercado de pe-

quenas e médias empresas de desenvolvimento de software no Brasil. É ba-

seado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade

do mercado brasileiro.

2 MODELOS DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Há mais de década vem se tentando encontrar um processo ou metodologia

que melhore a produtividade e qualidade dos sistemas de software desenvolvidos.

Algumas propostas tentaram formalizar a tarefa de desenvolver um software. Outras

aplicaram técnicas de gerenciamento de projeto no desenvolvimento de software,

mas como já vimos em aulas anteriores, sem o gerenciamento de projeto, projetos de

software podem facilmente sofrer atraso ou estourar o orçamento.

De acordo com as pesquisas do Standish Group, vimos que o percentual de

projetos bem sucedidos ainda não é suficiente. Isso indica que um grande número de

projetos de software não atende às expectativas em termos de funcionalidades, cus-

to, ou cronograma de entrega, portanto, acredita-se que ainda não existe um modelo

de processo perfeito para todas as aplicações. Na aula 7 verificaremos as principais

tendências para o processo de desenvolvimento de software.

De qualquer forma, devido à grande complexidade do desenvolvimento de sof-

tware, é muito importante que os desenvolvedores e as empresas envoldidas com de-

senvolvimento de projetos de software adotem um modelo de processo para garantir

o sucesso dos seus projetos.

2.2 Modelo Cascata

O modelo cascata é o mais antigo e tem como objetivo desenvolver as ativida-

des do processo de desenvolvimento na ordem seqüencial. A figura 30 ilustra o méto-



do sugerido pelo modelo cascata.

Figura 30 – Modelo Cascata

Os desenvolvedores que utilizam esse modelo estabelecem os requisitos, ana-

lisam os requisitos, projetam uma abordagem para solução, arquitetam um esboço do

software, implementam o código, testam - inicialmente os testes unitários e os testes

de sistema -, implantam e o mantêm. Ao final de cada atividade, o processo segue

para a próxima atividade. Essa característica é considerada uma das desvantagens

do modelo, pois novos requisitos podem surgir na atividade de projeto ou ainda na

atividade de implementação, porém a análise mais detalhada desses itens não é feita

devido à fase de especificação já ter sido desenvolvida.

Assim, se as iterações não são incluídas no planejamento, o processo não tem

meios para corrigir os erros nas etapas inicias, então o processo inteiro da engenharia

de software deve ser executado até o fim, resultando em funcionalidades de software

desnecessárias ou sem uso.

Esse modelo é adequado nas seguintes situações:

• Existe um conjunto de Requisitos estáveis e de alta qualidade – segundo

especialistas, Requisitos sempre sofrem mudanças, sendo esta visão muito

idealista;

• A duração do projeto é pequena, menor que dois anos;

• O sistema completo deve estar disponível de uma única vez.



2.3 Modelo Iterativo e Incremental

O Desenvolvimento iterativo e incremental descreve o desenvolvimento de pe-

quenas partes do software – funcionalidades ou módulos -, porém que sejam abran-

gentes de modo que auxilie os envolvidos a identificar se o desenvolvimento está

sendo feito de acordo com a necessidade e o especificado.

O processo iterativo é preferido por desenvolvedores porque lhes fornece um

potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente

o que quer, ou quando não se conhece bem todos os aspectos da solução.

Os processos de desenvolvimento ágil de software são construídos com os funda-

mentos do desenvolvimento iterativo. Os processos ágeis usam o feedback, mais que

o planejamento, como seus mecanismos de controle primário. O feedback é uma das

práticas que descreve o que foi produzido pelos testes regulares e das versões do

software desenvolvido.

Esse modelo é adequado nas seguintes situações:

• A liberação do software deve estar de acordo com um conjunto de prioridades

definidas nos Requisitos;

• É necessário melhorar a eficiência da integração do software com outra par-

tes de um sistema maior;

• Requerem-se, antecipadamente, evidências de que o produto será aceito.

A figura 31 ilustra o funcionamento do modelo iterativo e incremental.

Figura 31 – Modelo Iterativo e Incremental



2.4 Processo Unificado e RUP - Rational Unified Process

O Processo Unificado é um modelo desenvolvido pelos criadores da linguagem

UML: Ivar Jacobson, James Rumbaugh e Grady Booch. Esse modelo pode ser con-

siderado como o resultado de mais de 30 anos de experiência acumulada dos seus

criadores.

O processo unificado, ou UP, como é conhecido, é o primeiro processo de

desenvolvimento a explorar integralmente as capacidades da linguagem UML. Além

disso, baseia-se nas práticas comuns aos projetos de software indicados como bem

sucedidos.

O processo unificado de software ou RUP – Rational Unified Process – é o

processo de desenvolvimento de software criado com base no processo unificado. A

empresa Rational é a empresa fundada pelos “três amigos”, criadores da UML e do

Processo Unificado. A Rational foi comprada pela IBM no ano de 2003.

A fórmula a seguir, define de maneira resumida o conceito do processo de sof-

tware unificado:

RUP = Processo + Métodos + Linguagem UML

O desenvolvimento de sistemas, seguindo o RUP é um processo:

• Dirigido por casos de uso;

• Centrado na arquitetura;

• Iterativo e incremental.

Veja na figura 32 o processo unificado de software.

Figura 32 – Processo Unificado de Software - RUP



Síntese da Aula


1) O processo de desenvolvimento de software e as suas principais caracterís-

ticas;

2) As atividades do processo de desenvolvimento de software;

3) Os padrões do processo de desenvolvimento de software;

4) Os principais modelos do processo de desenvolvimento de software.


1) Assinale a alternativa incorreta. As características responsáveis pela crise de

software são:

a) Projetos estourando o orçamento;

b) Projetos estourando o prazo;

c) Projetos com planejamento bem definido;

d) Software com baixa qualidade.

2) A atividade do Processo de Desenvolvimento de Software responsável pela

entrevista com usuário e levantamento das informações é:

a) Análise de requisitos de software;

b) Especificação;

c) Manutenção;

d) Suporte e Treinamento de Software.

3) A atividade do Processo de Desenvolvimento de Software que impacta direta-

mente nas demais atividades de software é:

a) Análise de requisitos de software;



b) Especificação;

c) Manutenção;

d) Suporte e Treinamento de Software.

4) O modelo de processo totalmente compatível com a linguagem UML é:

a) Modelo Cascata;

b) Modelo Iterativo;

c) Modelo Incremental;

d) Modelo Unificado.



Aula 6

MODELANDO PROJETOS DE SOFTWARE

Nesta sexta aula você estudará sobre as principais ati-

vidades desenvolvidas na etapa de análise e projeto de

software. Estudará quais são as atividades dessa etapa, quais as

práticas comuns utilizadas para auxiliar no desenvolvimento das

atividades de modelagem e alguns exemplos de modelagem de

sistemas. Criará alguns diagramas UML com base na ferramenta

JUDE.

Bons Estudos!

Objetivos da Aula


• Enumerar as principais atividades para elaborar

os modelos de software;

• Caracterizar cada atividade da modelagem de software;

• Analisar os exemplos de práticas utilizados para modelar

projetos de software;

• Criar modelos utilizando a lingaugem UML.

Conteúdos da Aula



• Análise e Projeto de Software;




1 ANÁLISE E PROJETO DE SOFTWARE

A modelagem de software se dá principalmente na etapa de análise do projeto

de software, característica em que é aconselhável desenvolver um modelo, analisar

os detalhes de funcionamento por meio do modelo, aperfeiçoá-lo e, por fim, desenvol-

ver o produto final com base no modelo.

A etapa de análise é a etapa na qual se faz o levantamento da necessidade

existente e define-se de que forma o software a ser criado deverá solucionar essa ne-

cessidade. Em alguns ambientes, os desenvolvedores têm o mau costume de “pular”

a etapa de análise indo diretamente para a etapa de desenvolvimento – essa atitude

por ser justificada pela inexperiência dos desenvolvedores ou ainda por falta de um

modelo de processo de desenvolvimento de software definido.

Projetos de software que ocasionalmente não passaram por todas as ativida-

des definidas no processo de desenvolvimento de software, freqüentemente possuem

falhas na definição do software, ou seja, descobre-se, após o desenvolvimento que

o que foi feito não atende à necessidade existente. Dessa forma, é imprescindível

adotar e seguir um modelo para garantir o sucesso no desenvolvimento dos projetos

de software.

As principais atividades desenvolvidas na etapa de análise são:

• Levantamento de informações;

• Análise dos requisitos;

• Transformação dos requisitos em casos de uso e diagramas de casos de

uso;

• Modelagem dos diagramas de classes, seqüência, atividades e estado – a

modelagem de todos os diagramas vai depender da complexidade do projeto

de software;

• Desenvolvimento de protótipos de telas – atividade opcional.



1.2 Levantamento de Informações

Nessa etapa, o analista realiza o levantamento de informações com o usuário.

O analista pode utilizar várias técnicas como entrevistas com o usuário para descobrir

as necessidades existentes. As técnicas mais utilizadas para levantamento de infor-

mações com os usuários são:

• Entrevistas;

• Observação in loco - observação do processo na “casa” do usuário;

• Encontros/Reuniões.

Essas três técnicas são complementares e podem todas ser usadas numa

mesma análise de requisitos. A entrevista é normalmente a primeira técnica utilizada.

Os analistas entrevistam os usuários para definir os objetivos gerais e as restrições

que o software deverá ter. A entrevista deve ser feita de forma objetiva visando obter

o máximo de informações do usuário.

Na observação in loco, os analistas devem estar inseridos na rotina de trabalho

da organização tentando entender e descrever as principais atividades realizadas.

Devem ser identificadas quais são as atividades que podem ser automatizadas; quem

são os potenciais usuários; quais tarefas eles querem realizar com a ajuda do novo

sistema, etc. A observação deve ser complementada com entrevistas específicas com

os futuros usuários.

Os encontros são reuniões envolvendo analistas, clientes e usuários e têm

como objetivo principal o levantamento de informações, a descrição dos problemas

atuais e as metas futuras. É aconselhável que os encontros sejam realizados em um

local neutro - fora da organização e que as informações levantadas, sejam afixadas

em painéis, na sala de encontro para que possam ser analisadas e validadas pelos

clientes e usuários. Ao final do encontro, os analistas devem elaborar um relatório

descrevendo os requisitos analisados.

Independente da técnica de levantamento utilizada, o analista deve estar sem-

pre atento às informações fornecidas pelo usuário, pois cada detalhe mencionado por

usuário, muitas vezes pode resultar em mudanças no planejamento que o analista já

estava realizando.



Nem sempre o usuário tem todas as informações que o analista necessita. Mui-

tas vezes, o usuário tem informação sobre o seu trabalho no momento, mas a diretoria

tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de

conhecimento do usuário. Assim o analista deve sempre consultar outras pessoas

além dos usuários da aplicação.

A tabela 10 mostra um exemplo de questionário que pode ser aplicado em uma entre-

vista com o usuário.

Tabela 10 – Exemplo de QuestionárioQual é o objetivo do Sistema?1. Que área vai atender?2. Que tipo e quantos usuários estarão interagindo com o sistema?3. Quais são as principais funcionalidades que o sistema deverá possuir?4. Quais funcionalidades os usuários poderão acessar?5. É necessário utilizar perfil de usuário para definir acesso aos usuários?6. Qual plataforma o sistema utilizará?7. Qual o banco de dados que irá utilizar?8. O sistema estará alocado dentro da empresa ou em um servidor de terceiro?9. Qual é o prazo de entrega?10. Necessita de uma equipe para o treinamento do Projeto?11. Há disponibilidade de alguém para acompanhar o desenvolvimento?12. Necessita treinamento no processo a ser sistematizado?13. Necessidade de alguma linguagem específica?14. Já há informações em arquivos ou banco de outros sistemas?15. Sistema terá integração com outros sistemas atuais?16. Há uma limitação de orçamento?17. Qual é a configuração padrão das máquinas da empresa(Windows 95,98,2000, XP ou Linux)?18. Haverá manutenção mensal no sistema?19. O sistema atenderá mais franquias da própria empresa?20.

1.3 Levantamento de Informações

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do

sistema que definem as diversas propriedades do sistema. Um conjunto de requisitos

pode ser definido como uma condição ou capacidade necessária que o software deve

possuir para:

1. Que o usuário possa resolver um problema ou atingir um objetivo;

2. Ou atender às necessidades e/ou restrições da organização ou dos outros



componentes do sistema.

Tradicionalmente, os requisitos de software são separados em requisitos

funcionais e não-funcionais. Os requisitos funcionais são a descrição das diversas

funções que clientes e usuários querem ou precisam que o software ofereça. Definem

a funcionalidade desejada do software. O termo função é usado no sentido genérico

de operação que pode ser realizado pelo sistema, seja através comandos dos usu-

ários ou pela ocorrência de eventos internos ou externos ao sistema. Exemplos de

requisitos funcionais:

1. “O software deve possibilitar o cálculo dos gastos diários, semanais, men-

sais e anuais com pessoal”.

2. “O software deve emitir relatórios de compras a cada quinze dias.”

3. “Os usuários devem poder obter o número de aprovações, reprovações e

trancamentos em todas as disciplinas por um determinado período de tempo.“

A especificação de um requisito funcional deve determinar o que se espera

que o software faça, sem a preocupação de como ele faz. É importante diferenciar a

atividade de especificar requisitos da atividade de especificação que ocorre durante o

desenvolvimento do software. Na especificação do software, deve-se tomar a decisão

de quais funções o sistema efetivamente terá para satisfazer o que os usuários que-

rem / necessitam.

Requisitos não-funcionais são as qualidades globais de um software, como

manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente,

esses requisitos são descritos de maneira informal e são difíceis de validar. Exemplos

de requisitos não-funcionais:

1. “A base de dados deve ser protegida para acesso apenas de usuários auto-

rizados”.

2. “O tempo de resposta do sistema não deve ultrapassar 30 segundos”.

3. “O software deve ser operacionalizado no sistema Linux”.

4. “O tempo de desenvolvimento não deve ultrapassar seis meses”.

A necessidade de se estabelecer os requisitos de forma precisa é crítica à me-



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

influência uns sobre os outros. Por exemplo, o requisito de que o software deve ter

grande portabilidade, ser implementado em Java para possibilitar o acesso por celu-

lar, ou dispositivos móveis – pode implicar em que o requisito desempenho não seja

satisfeito.

O resultado final da análise e especificação de requisitos e das outras ativida-

des da fase de definção deve ser apresentado aos clientes para que possam validá-lo.

Esse documento oferece a concordância entre clientes, analistas e desenvolvedores

sobre o que deve ser desenvolvido. É utilizando esse documento que as atividades da

fase de desenvolvimento – codificação – serão validadas.

Cada desenvolvedor utiliza um modelo específico para elaborar este documen-

to. A sua estrutura, muitas vezes, depende do método que está sendo utilizado. Em

linhas gerais, esse modelo deve ser basicamente textual, utilizando o mínimo de ter-

mos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a

visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema.

A tabela 11 ilustra uma lista de requisitos funcionais e não-funcionais de um sis-

tema de software. A lista de requisitos se refere às informações levantadas para uma

faculdade que necessita de aplicação para controlar processos acadêmicos como: vi-

sualização de notas pelos alunos, cadastro de disciplinas, alocação de recursos para

as turmas, etc.

Tabela 11 – Lista resumida de requisitos# Descrição Tipo

1O sistema deve permitir aos alunos visualizar as notas das disciplinas por semestre letivo.

Requisito Funcional

2O sistema deve permitir o lançamento das notas dos alu-nos por disciplina pelos professores.

Requisito Funcional

3

O sistema deve permitir a abertura de turmas para uma disciplina, com a definição de sala e laboratórios a serem utilizados e dos horários e dias da semana em que haverá aulas.

Requisito Funcional

4 O sistema deve ser desenvolvido para a plataforma WEB Requisito Não-Funcional



1.4 Transformação dos requisitos em casos de uso e diagramas de casos de

uso

Após a definição dos requisitos do sistema de software, é possível dar início

à identificação dos atores e casos de uso para a elaboração do diagrama de casos

de uso. Os atores devem ser encarados como os agentes externos ao sistema, por

exemplo: usuários, outros sistemas, computadores externos, impressoras etc. Já os

casos de uso serão as funcionalidades do sistema ou os requisitos funcionais do sis-

tema.

Para auxiliar na identificação dos atores do sistema, podem ser utilizadas as

seguintes questões:

1. Quem irá utilizar as funções principais do sistema?

2. Quem precisará do sistema para realizar as suas tarefas diárias?

3. Quem irá manter, administrar e deixar o sistema funcionando?

4. Existe interação com outros sistemas? Quais?

5. Quem ou o que está interessado nos resultados (valores) que o sistema

produz?

Com base na lista de requisitos, disponível na tabela 11, e as questões acima

citadas, identificaram-se os seguintes atores:

• Aluno;

• Professor;

• Secretaria.

Para auxiliar na identificação dos casos de uso, podem ser utilizadas as se-

guintes questões:

1. Quais funções os atores necessitam do sistema?

2. O que o ator deve fazer?

3. O ator precisa ler, escrever, apagar, modificar ou armazenar alguma informa-

ção no sistema?

4. O ator precisa ser informado sobre eventos que acontecem no sistema?

5 .O ator precisa notificar o sistema de alguma coisa?



6. O que os eventos 4 e 5 representam em termos de funcionalidade?

7. Os atores podem ter as suas tarefas diárias simplificadas ou feitas de modo

eficiente se alguma nova função for adicionada?

Com base na lista de requisitos, disponível na tabela 11, e as questões acima

citadas, identificaram-se os seguintes casos de uso:

• Visualiza Notas;

• Lança Notas;

• Cadastra Disciplina;

• Abre Turmas;

• Define Horário das Turmas.

Após a identificação dos atores e casos de uso, é possível modelar o diagrama

de casos de uso e, caso seja necessário, detalhar / documentar o caso de uso textual-

mente. O detalhamento do caso de uso é geralmente utilizado quando a funcionalida-

de referente ao caso de uso é um tanto complexa. Caso contrário, um detalhamento

maior não é necessário. O detalhamento do caso de uso pode utilizar o modelo suge-

rido na tabela 5 – aula 4.

Vejam na figura 33 o diagrama de casos de uso modelado de acordo com a

lista de requisitos – tabela 11 – e a identificação dos atores e casos de uso do sistema

de software.



Figura 33 – Diagrama de Casos de Uso

O diagrama ilustrado na figura 33 foi modelado na ferramenta JUDE. Para

elaborar os diagramas UML utilizando o JUDE, basta você seguir as seguintes instru-

ções:

1. Abra a ferramenta por meio do menu: Iniciar >> Programas >> JUDE Com-

munity;

2. Crie um novo arquivo: .jude que possuirá todos os diagramas e modelos

do seu projeto de software clicando em: File >> New ou pelo ícone de atalho:

Create a New File. Dica: para cada projeto de software crie sempre um arquivo

diferente com o nome do projeto. Um arquivo jude poderá possuir vários dia-

gramas – podendo ser várias versões de um mesmo diagrama – dessa forma,

sempre coloque um nome para os diagramas identificando a situação ou fun-

cionalidade que o diagrama representa. Isso facilitará a tarefa de modelagem

de software.

3. Para criar um novo diagrama, basta clicar na opção: Diagram na barra de

ferramentas e selecionar o diagrama desejado. Como a ferramenta está dis-

ponível apenas no idioma inglês, segue abaixo a tradução para os principais

diagramas UML:

a) Diagrama de Caso de Uso = UseCase Diagram



b) Diagrama de Classes = Class Diagram

c) Diagrama de Seqüência = Sequence Diagram

d) Diagrama de Estado = StateChart Diagram

e) Diagrama de Atividade = Activity Diagram

4. Modele o diagrama utilizando os elementos gráficos disponíveis. Se ne-

cessário, volte à aula 4, onde são abordados todos os elementos gráficos dos

diagramas.

1.5 Modelagem dos diagramas de classes, seqüência, atividades e estado

Após a definição do diagrama de casos de uso e a sucessiva validação pelo

cliente - usuário final -, é possível dar continuidade no processo de modelagem do

projeto de software. Não há uma seqüência lógica para a elaboração dos demais

diagramas e também não há uma quantidade específica para cada modelo. A quan-

tidade de diagramas a ser modelado deve estar de acordo com a necessidade de

detalhamento do sistema de software, a fim de abstrair ao máximo a complexidade do

software.

Dos quatro diagramas citados, o diagrama de classes é o mais importante e

mais utlizado nos projetos de softwatre, pois é com base nesse diagrama que as clas-

ses e os objetos do sistema serão criados. Os demais diagramas, como já informado,

poderão ser modelados de acordo com a complexidade do sistema e/ou funcionalida-

des que estão sendo modeladas.

Para auxiliar na identificação das classes do sistema, podem ser utilizadas as

seguintes questões:

1. Existem informações que devem ser registradas ou analisadas?

2. Existe interação com sistemas externos?

3. Existem padrões, bibliotecas, pacotes, componentes, etc a serem utiliza-

dos?

4. Existem informações que devem ser manipuladas de qualquer forma? Quais?

(Detalhar atributos e operações)

5. Existem representações organizacionais?



6. Quais papéis representam os atores no negócio?

7. Existem dispositivos que serão manipulados pelo sistema?

Com base na lista de requisitos da tabela 11 e definição dos casos de uso do

sistema – funcionalidades do sistema (figura 33) – foram identificadas as seguintes

classes para o projeto de software:

• Classes que irão manter os dados dos atores:

• Aluno;

• Professor;

• Secretaria.

• Classes que irão manter os dados das informações do sistema:

• Semestre;

• Disciplina;

• Turma;

• Horário;

• Sala;

• Laboratório;

• Nota.

Veja na figura 34 o diagrama de classes sugerido para o sistema.



Figura 34 – Diagrama de Classes do Sistema

O diagrama de seqüência irá representar o funcionamento interno do sistema,

em relação a uma ou mais funcionalidades. Pode-se utilizar como referência a defini-

ção e o detalhamento dos casos de uso identificados para o sistema. No diagrama de

seqüência será ilustrada a ação de um ator e a troca de mensagens entre os objetos

do sistema, a fim de realizar a operação iniciada pela ação do ator.

Veja na figura 35 o diagrama de seqüência modelado para descrever o funcio-

namento interno do caso de uso: Visualiza Nota.



Figura 35 – Diagrama de Seqüência do Caso de Uso: Visualiza Nota

O diagrama de estado irá ilustrar o funcionamento interno de um objeto do

sistema. Nesse diagrama serão ilustrados os estados que um objeto poderá assumir,

dependendo da operação realizada pelo ator ou pelo próprio objeto. Esse diagrama

deve ser utilizado somente para os objetos que possuem uma complexidade conside-

rável e necessitam de detalhamento para melhor análise.

A figura 36 ilustra o diagrama de estado modelado para descrever o funciona-

mento interno do objeto: Turma.

Figura 36 – Diagrama de Estado do Objeto: Turma

O diagrama de atividades irá ilustrar o fluxo de dados de uma ou mais funcio-



nalidades, além da interação dessa funcionalidade com os atores do sistema. Esse

diagrama também poderá ser modelado com base na definição e detalhamento dos

casos de uso identificados no sistema.

Veja na figura 37 o diagrama de atividades modelado para descrever o fluxo de

dados do caso de uso: Visualiza Nota.

Figura 37 – Diagrama de Atividade do Caso de Uso: Visualiza Nota

1.6 Desenvolvimento de protótipos de telas

Essa atividade é uma tarefa opcional, pois sua finalidade é demonstrar de for-

ma visível o layout das telas do sistema a ser desenvolvido. É muito útil para sistemas

extremamente complexos e com grande quantidade de telas, porém, mesmo nesse

caso, é aconselhável desenvolver os protótipos das telas mais complexas, para evitar



desperdício de tempo em atividades que não irão agregar qualidade ou produtividade

ao produto final.

Ferramentas CASE como o VISIO da Microsoft permitem o desenvolvimento de

protótipos com grande qualidade e proximidade do layout das telas do sistema real.

Veja na figura 38 um exemplo de protótipo de tela desenvolvido com o VISIO.

Figura 38 – Protótipo de Tela

Síntese da Aula


1) As principais atividades desenvolvidas na etapa de análise e projeto de sof-

tware;

2) As melhores práticas para o desenvolvimento das atividades;

3) Como modelar os principais diagramas UML;

4) Exemplos de métodos e técnicas que podem ser aplicadas durante a mode-

lagem de projetos de software.




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

a) Identificação dos Atores do Sistema;

b) Identificação dos Casos de Uso do Sistema;

c) Elaboração do Diagrama de Casos de Uso;

d) Identificação das Classes do Sistema;

e) Elaboração do Diagrama de Classes.

# Descrição Tipo

1O sistema deve permitir ao Funcionário ca-dastrar Clientes contendo os dados: nome, endereço, e telefone

Requisito Funcional

2

O sistema deve permitir ao Funcionário ca-dastrar Cidades que representam os lugares abrangidos pela empresa de transportes e contêm o nome da cidade, o estado a que pertence e o valor para a taxa de entrega

Requisito Funcional

3

O sistema deve permitir ao Funcionário ca-dastrar Fretes contendo um código, uma des-crição, o peso total, um cliente e a cidade de destino, não podendo haver um frete sem os dados citados. Cada frete deve ter ainda o seu valor, que deve ser calculado por meio do peso multiplicado por um valor fixo, acrescido da taxa de entrega da cidade de destino

Requisito Funcional

4 O sistema deve ser para plataforma WEB Requisito Não-Funcional



Aula 7

TENDÊNCIAS DO PROCESSO DE ENGENHARIA DE SOFTWARE

Nesta aula você estudará sobre as principais tendências

para o desenvolvimento e gerenciamento de sistemas de

software. Verificará os principais temas discutidos pela comunida-

de de engenharia de software.

Bons Estudos!

Objetivos da Aula


• Identificar as principais tendências para o desenvolvimento

e gerenciamento de projetos de software.

Conteúdos da Aula



• A importância do Software;

• Metodologias Ágeis;




1 A IMPORTÂNCIA DO SOFTWARE

O software de computador é uma dentre poucas tecnologias-chave que causa-

ram impacto sobre quase todos os aspectos da sociedade moderna durante a década

de 1990. É um mecanismo para automatizar os negócios, a indústria e o governo, um

meio de transferir novas tecnologias, um modo de captar valiosa experiência para ser

usada por outros, um meio de diferenciar os produtos de uma empresa dos de seus

concorrentes e uma janela para o conhecimento corporativo coletivo (PRESSMAN,

1995, p. 1010).

É realmente impressionante a capacidade com que o software teve de se in-

filtrar em todas as áreas de atuação da sociedade. Atualmente, é muito difícil irmos

a um lugar ou qualquer estabelecimento que não possua um software ou sistema de

informação que permita gerenciar, automatizar ou suportar algumas das atividades.

É possível também, verificar a evolução dos softwares que vêm sendo desen-

volvidos atualmente. A disseminação e busca pela melhoria no desenvolvimento de

software também aumentou após a popularização dos meios de comunicação e servi-

ços oferecidos por meio da Internet. É muito comum, nos dias atuais, que as pessoas

realizem compras, como a compra de um livro, por exemplo, em uma loja virtual dispo-

nível na Internet. Também é bastante comum que empresas de segmentos diversos

tenham o seu cartão de visitas disponível em forma de um site na Internet.

E a evolução não pára por aí. O software tem atingido ambientes diversos

também, fora do mundo dos computadores e sua rede mundial. Tendências como:

softwares embarcados – sistema específico que faz parte de um minicomputador,

máquina ou sistema mais amplo -, tecnologias móveis – sistema desenvolvido para

aparelhos de celulares e outros dispositivos móveis – e sistemas para televisão digital

têm proporcionado uma grande evolução na área da engenharia de software, que vem

expandindo com grande velocidade a sua área de atuação.

Conforme a área de atuação da engenharia de software foi aumentando, mu-

danças no processo de desenvolvimento e nas técnicas utilizadas começaram a sur-

gir. O objetivo dessas mudanças é sempre a melhoria no processo de desenvolvi-

mento de projetos de software a fim de produzir softwares com maior produtividade e



qualidade.

Segundo PRESSMAN (2002, p. 1013), as mudanças que afetarão a engenha-

ria de software ao longo das próximas décadas serão influenciadas a partir de quatro

direções simultâneas: (1) as pessoas que fazem o trabalho; (2) o processo que elas

aplicam; (3) a natureza da informação; (4) e a tecnologia de computação subjcente.

1.2 Software baseada em Componentes

Engenharia de Software Baseada em componentes é um ramo de Engenharia

de Software, com ênfase na decomposição dos sistemas em componentes funcionais

e lógicos com interfaces bem definidas, usadas para comunicação entre os próprios

componentes.

Componentes estão em um nível de abstração mais alto que do que Objetos,

porém comunicam-se por troca de mensagens contendo dados. Os componentes

possuem uma interface e também empregam regras de herança. São definidos para

oferecer certo nível de serviço. No caso dos componentes “comerciais de prateleira”,

o engenheiro de software sabe pouco ou nada sobre o seu funcionamento interno.

Ao invés disso, ao engenheiro de software é dada apenas uma interface externa bem

definida a partir da qual ele deve trabalhar.

Ao contrário de objetos em OO, os componentes são usualmente construídos a

partir de muitos “objetos” de software e fornecem uma unidade de funcionalidade co-

erente. Os assim chamados “objetos” trabalham em conjunto para realizar uma tarefa

específica em um dado nível de serviço.

A grande vantagem de se trabalhar com componentes é a possibilidade de

reutilização, por meio da qual tanto a produtividade quanto a qualidade seriam bene-

ficiadas, pois um componente deve possuir exatidão na função que desempenha.

1.3 Padrões de Projetos

Os padrões de projeto, também muito conhecido pelo termo original em inglês:

Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimen-

to de sistemas de software orientados a objetos. Um padrão de projeto estabelece um



nome e define o problema, a solução, quando aplicar essa solução e suas conseqü-

ências.

Os padrões de projeto visam facilitar a reutilização de soluções de desenho -

isto é, soluções na fase de projeto do software, sem considerar reutilização de código.

Também acarretam um vocabulário comum de desenho, facilitando comunicação, do-

cumentação e aprendizado dos sistemas de software.

O movimento ao redor de padrões de projeto ganhou popularidade com o li-

vro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em

1995. Os autores desse livro são Erich Gamma, Richard Helm, Ralph Johnson e John

Vlissides, conhecidos como a “Gangue dos Quatro” (Gang of Four) ou simplesmente

“GoF”. Posteriormente, vários outros livros do estilo foram publicados, como Applying

UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Itera-

tive Development, que introduziu um conjunto de padrões conhecidos como GRASP

(General Responsibility Assignment Software Patterns).

2 METODOLOGIAS ÁGEIS

Um desafio constante da área de Engenharia de Software é a melhoria no

processo de desenvolvimento de software. Mesmo com a evolução de métodos, téc-

nicas e ferramentas, nem sempre se consegue entregar software em prazos e custos

estabelecidos nem sempre é conseguida. Vimos na figura 1 (aula 1), de acordo com

as pesquisas realizadas pelo órgão Standish Group, que apenas 34% dos projetos de

software são bem-sucedidos.

De acordo com os pesquisadores da área de metodologias ágeis, uma das

causas desse problema pode ser o excesso de formalidade nos modelos de processo

propostos nos últimos 30 anos. Documentações extensivas e artefatos que muitas ve-

zes são desenvolvidos no início do projeto e depois “engavetados” durante o processo

de desenvolvimento, são apontadas como as principais causas de não sucesso dos

projetos.

Com o avanço sucessivo da tecnologia e o aumento da velocidade de sua

propagação, surge cada vez mais a necessidade de desenvolver software de forma

mais rápida, porém sempre privando pela qualidade. Esse aumento na capacidade



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

aplicação de métodos ágeis e padrões organizacionais de processo.

Há alguns anos, um grupo de veteranos na área de software se reuniu, nos

EUA, para discutir formas de melhorar o desempenho de seus projetos. Embora cada

envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de

software ter sucesso, todos concordavam que, em suas experiências prévias, um pe-

queno conjunto de princípios sempre era respeitado quando os projetos davam certo.

Com base nisso, criaram o Manifesto para o Desenvolvimento Ágil de Software

– em 17 de fevereiro de 2001 -, freqüentemente chamado apenas de Manifesto Ágil.

Os princípios propostos pelo Manifesto Ágil segundo Beck ( 2001), são:

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós

mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valori-

zar:

• Indivíduos e interações são mais importantes que processos e ferramen-

tas;

• Software funcionando é mais importante do que documentação detalhada;

• Colaboração dos clientes é mais importante do que negociação de contra-

tos;

• Adaptação às mudanças é mais importante do que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à es-

querda.”

O “Manifesto Ágil” não rejeita os processos e ferramentas, a documentação,

a negociação de contratos ou o planejamento, mas simplesmente mostra que eles

têm importância secundária quando comparado com os indivíduos e interações, com

o software estar executável, com a colaboração do cliente e as respostas rápidas a

mudanças e alterações. Esses conceitos aproximam-se melhor com a forma que pe-

quenas e médias organizações trabalham e respondem a mudanças.

Assim, foi a partir do “Manifesto Ágil” que ocorreu a popularização dos métodos

ágeis que passaram a ser usados em empresas, universidades, institutos de pesqui-

sa e até em agências governamentais. Algumas das metodologias ágeis existentes



são:

• XP (eXtreme Programming);

• DSDM (Dynamic Systems Development Method);

• Família Crystal;

• ASD (Adaptive Software Development);

• SCRUM;

• FDD (Feature-driven development);

• LD (Lean Development);

• Open Source.

Com exceção dos autores das metodologias: LD e OpenSource, os demais

autores das metodologias citadas participaram da criação do Manifesto Ágil, portanto,

possuem princípios em comum.

Síntese


1) A importância do software;

2) Conceitos básicos sobre Engenharia de Software Baseada em Componen-

tes;

3) Conceitos básicos sobre Padrões de Projeto;

4) Conceitos básicos sobre Metodologias Ágeis.



Exercícios propostos

1) Assinale a alternativa incorreta. De acordo com PRESSMAN, as mudanças

que podem afetar a Engenharia de Software são:

a) Pessoas que desenvolvem;

b) Processo de desenvolvimento;

c) Natureza da Informação;

d) Certificação de Padrão.

2) Os componentes:

a) Possuem várias funcionalidades;

b) Possuem uma interface bem definida;

c) Implementam Herança;

d) Comunicam-se por meio de troca de mensagens de dados.

3) Assinale a alternativa incorreta. É objetivo das Metodologias Ágeis:

a) Entregar software funcionando;

b) Aumentar o nível de documentações;

c) Incluir o cliente em todo o processo de desenvolvimento;

d) Adaptação às mudanças.



Aula 8

ESTUDO DE CASO: MODELANDO UM PROJETO DE SOFTWARE

Caros alunos, chegamos à última aula da disciplina. Nesta

aula aplicaremos os conceitos de modelagem vistos até

agora, a fim de consolidar o conhecimento no processo de modela-

gem de produtos de software.

Bons Estudos!

Objetivos da Aula


• Desenvolver as principais atividades de modelagem de

software;

• Elaborar os diagramas UML com a ferramenta JUDE.

Conteúdos da Aula



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

de software.



1 DEFINIçÃO DO ESTUDO DE CASO

Nesta aula, apresentaremos uma descrição inicial do estudo de caso que guia-

rá as atividades do processo de desenvolvimento de software e a modelagem de sis-

temas de software.

O estudo de caso refere-se a um software que possibilite a gestão de festas

de casamento. O software deverá permitir ao usuário, dentre outras coisas, escolher

o buffet, se haverá grupo musical, escolher tipo de decoração, entre outros itens. O

usuário também poderá definir uma loja para disponibilização da lista de presentes. O

sistema deverá emitir relatório das vendas realizadas por período e gerar orçamento.

Com base na definição do estudo de caso, vamos iniciar a atividade de análise e

projeto de software e, por conseguinte a tarefa de identificação dos requisitos do sof-

tware.

1.2 Identificação dos Requisitos

Para auxiliar na tarefa de identificação dos requisitos de software, vamos revi-

sar as possíveis definições para requisitos:

• Característica do sistema ou a descrição de algo que o sistema seja capaz de

realizar para atingir seus objetos;

• As descrições de funções e restrições do sistema;

• Propriedade que o software deve exibir para resolver algum problema no

mundo real;

• Condição ou capacidade que deve ser alcançada ou estar presente em um

sistema para satisfazer um contrato, padrão, especificação ou outro documen-

to formalmente imposto.

Enfim, podemos traduzir a definição de requisitos como um conjunto de ne-

cessidades explicitadas pelo cliente que deverão ser atendidas para solucionar um

determinado problema de negócio do qual o cliente faz parte.

Os requisitos são classificados em dois tipos:



• Funcionais – diretamente ligados à funcionalidade do software, descrevem

as funções que o software deve executar;

• Não-Funcionais – expressam condições que o software deve atender ou

qualidades específicas que o software deve ter.

Os requisitos identificados para o software do estudo de caso proposto, podem

ser visualizados na tabela 12.

Tabela 12 – Requisitos do sistema do estudo de caso# Descrição Tipo

1O sistema deve permitir que o gerente cadastre salões de festas

Requisito Funcional

2O sistema deve permitir que o gerente cadastre pro-fissionais

Requisito Funcional

3O sistema deve permitir que o gerente realize o cadas-tro de serviços utilizados em uma festa de casamento, como buffet e carros utilizados

Requisito Funcional

4O sistema deverá permitir que o cliente realize o ca-dastro da lista de convidados

Requisito Funcional

5O sistema deverá permitir que o cliente elabore a con-figuração da festa

Requisito Funcional

6O sistema deverá permitir a geração do orçamento para o cliente

Requisito Funcional

7O sistema deverá permitir que o gerente realize a im-pressão de relatório de festas

Requisito Funcional

8O sistema deverá permitir que o cliente cadastre a lista de presentes

Requisito Funcional

9O sistema deverá permitir que o gerente realize o ca-dastro de usuários

Requisito Funcional

10O sistema deverá permitir a autenticação dos usuá-rios

Requisito Funcional

11O sistema deve ser compatível com os navegadores Internet Explorer e Firefox

Requisito Não-Funcional

12O sistema deve garantir que o tempo de retorno das consul-tas seja inferior a 5 segundos

Requisito Não-Funcional



1.2 Identificação dos Atores e Casos de Uso

Após a identificação dos requisitos de software e sua classificação em fun-

cionais e não-funcionais, podemos dar início às tarefas de identificação dos atores e

casos de uso do sistema.

Apenas para relembrarmos, os atores são os agentes externos ao sistema,

porém possuem acesso às funcionalidades disponíveis no sistema. Essas funcionali-

dades são os próprios casos de uso.

Com base na definição inicial do sistema proposto pelo estudo de caso e a

identificação e definição dos requisitos de software, encontramos os seguintes atores

e casos de uso:

• Atores: Gerente, Cliente;

• Casos de Uso:

• Cadastra Salão de Festa;

• Cadastra Serviço;

• Cadastra Profissional;

• Configura Festa;

• Gera Relatório;

• Cadastra Usuário;

• Autentica Usuário.

Vimos que, dependendo da complexidade da funcionalidade – caso de uso – é

possível também nesta fase elaborar o detalhamento do caso de uso de modo textual.

No sistema de festas de casamento, proposto pelo estudo de caso, elaboraremos o

detalhamento do caso de uso: Autentica Usuário. Esse detalhamento permite uma

análise mais criteriosa a respeito do funcionamento do caso de uso e suas principais

características.

Veja na tabela 13 o detalhamento elaborado para o caso de uso: Autentica Usu-

ário.



Tabela 13 – Especificação do Caso de Uso: Autentica UsuárioCaso de Uso: Autentica Usuário

Sumário:Efetuar o login dos usuários no sistema de acordo com o perfil de cada um e exibir as telas permitidas para cada perfil.

Ator Primário: Gerente

Ator Secundário: Cliente

Pré-Condição: Usuário acessa o sistema

Fluxo Principal:

1. O sistema apresenta formulário contendo as informações: Login e Senha, além das opções: Entrar e Cancelar.2. Usuário informe os dados e seleciona a opção: Entrar [A1].3. O sistema verifica a autenticidade dos dados informados pelo usuá-rio [A2].4. O sistema autentica o usuário e apresenta a tela com as opções que ele pode acessar.5. Caso de uso é encerrado.

Fluxo Alternativo:

A1. Usuário seleciona a opção: Cancelar a. Caso de Uso é encerradoA2. Login ou senha inválida a. O sistema apresenta a mensagem: “Usuário ou senha inválido” e a opção: OK. b. O usuário seleciona a opção OK. c. O caso de uso retorna para o passo 2 do fluxo principal.

1.4 Elaborando Diagrama de Casos de Uso

Após a identificação dos atores e os casos de uso, é possível elaborar o dia-

grama de casos de uso que irá ilustrar a relação dos atores com as funcionalidades

do sistema – casos de uso do sistema. A figura 39 ilustra o modelo de diagrama de

casos de uso proposto para o estudo de caso.

Figura 39 – Diagrama de Casos de Uso do Estudo de Caso



1.5 Identificando as Classes do Estudo de Caso

A partir da identificação dos atores e casos de uso e da elaboração do diagra-

ma de casos de uso, é possível iniciar a tarefa de identificação das classes do sistema

do estudo de caso proposto.

Para identificar as classes, deve-se utilizar o conhecimento sobre o domínio do

problema – negócio que está sendo modelado – e a especificação de requisistos de

software elaborada. Deve-se procurar na especificação de requisitos, conceitos que

representem objetos do mundo real e que necessitam ser manipulados e/ou armaze-

nados pelo sistema.

Para o estudo de caso, foram identificadas as seguintes classes:

• Salão;

• Profissional;

• Serviço;

• Festa;

• Loja;

• Presente;

• Lista de Presente;

• Lista de Convidado;

• Convidado;

• Usuário.

1.6 Elaborando o Diagrama de Classes

Após a identificação das classes do sistema, podemos iniciar a elaboração do

diagrama de classes. Nessa etapa, devem ser realizadas as seguintes tarefas:

1. Identificação dos atributos das classes – atributos são as propriedades que

caracterizam o objeto;

2. Identificação das operações das classes – operações definem as ações que

um objeto pode realizar;

3. Identificação dos relacionamentos entre as classes;

4. Revisão do modelo elaborado.



Para o estudo de caso proposto, com base nas atividades de modelagem já

realizadas, foi elaborado o diagrama de classes ilustrado na figura 40.

Figura 40 – Diagrama de Classes do Estudo de Caso

1.7 Elaborando os Diagramas de Seqüência, Estados e Atividades

Como vimos na aula 6 – Modelando Projetos de Software – a elaboração dos

diagramas de seqüência, estados e atividades devem ser realizadas de acordo com

a complexidade do sistema de software a ser desenvolvido. No estudo de caso pro-

posto, elaboraremos apenas o diagrama de seqüência de uma das funcionalidades

do sistema. Os demais diagramas ficam como sugestão de lição de casa para você

treinar as habilidades e conhecimentos adquiridos na disciplina.

O diagrama de seqüência que elaboraremos, representa o funcionamento in-



terno do caso de uso: Autentica Usuário. A elaboração do diagrama de seqüência será

sempre feito com base na especificação dos requisitos de software, definição do caso

de uso e modelo de classes elaborado – diagrama de classes.

A figura 41 ilustra o diagrama de seqüência proposto.

Figura 41 – Diagrama de Seqüência do Estudo de Caso Proposto



CONCLUSÃO

Possuir um software que auxilie em tarefas diversas tornou-se algo muito co-

mum nos dias de hoje. Porém, mesmo com a grande evolução que o software vem

sofrendo nas últimas décadas e da quantidade e diversidade de tecnologias que sur-

giram; desenvolver software ainda é considerado uma atividade complexa.

A questão central: complexidade gira em torno, principalmente, das etapas ini-

ciais do projeto de software, consideradas como primordiais para o sucesso do produ-

to resultante do processo. Nessas etapas, é realizada a compreensão do problema

de negócio a ser solucionado pelo software, portanto, são etapas que requerem um

alto grau de experiência – por parte dos desenvolvedores – e grande atenção, a fim

de identificar todos os requisitos e as possíveis variações decorrentes do processo de

desenvolvimento de software.

Portanto, é imprescindível aos profissionais de informática, em especial àque-

les que desejam trabalhar com desenvolvimento de software, possuir o conhecimento

dos principais assuntos relacionados ao tema e também das práticas utilizadas no

processo de desenvolvimento de software. Esse conhecimento irá possibilitar ao pro-

fissional diversas oportunidades e habilidades para o desenvolvimento de projetos de

sucesso.

Assim, esse módulo teve como objetivo principal fazer uma introdução aos co-

nhecimentos básicos sobre os principais elementos dos projetos de software e às

melhores práticas para o processo de desenvolvimento.



REFERÊNCIAS

BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponível em:

http://www.agilemanifesto.org.

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Elsevier, 2002.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio

de Janeiro: Elsevier, 2005.

Dicionário Aurélio Online. Disponível em: http://200.225.157.123/dicaureliopos/

PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Makron Books,

1995.

WIKIPÉDIA, a enciclopédia livre. Artigos Eletrônicos. Disponível em: http://

pt.wikipedia.org/



APÊNDICE 1

1 O PARADIGMA DA ORIENTAçÃO A OBJETOS

Um paradigma é a forma de abordar um problema. Alan Kay, um dos pais do

paradigma da orientação a objetos, imaginou o funcionamento do sistema de software

como o de um ser vivo. Nesse sistema, cada “célula” interagiria com outras células

por meio de mensagens para realizar um objetivo comum.

Alan Kay pensou em construir um sistema de software a partir de agentes autô-

nomos (atuais objetos) que interagem entre si. Assim, foram estabelecidos os seguin-

tes princípios da orientação a objetos:

Qualquer coisa é um objeto;

Objetos realizam tarefas por meio da requisição de serviços a outros objetos;

Cada objeto pertence a uma determinada classe;

Uma classe agrupa objetos similares;

A classe é um repositório para comportamento associado ao objeto;

Classes são organizadas em hierarquias.

Exemplo da utilização dos princípios da OO:

Para comprar uma pizza 1. VOCÊ que está muito ocupado, pede sua pizza por tele-

fone;

VOCÊ2. informa ao ATENDENTE seus dados e as características da pizza que de-

seja comprar;

O 3. ATENDENTE atende sua solicitação e comunica ao PIZZAIOLO seu pedido;

O 4. PIZZAIOLO faz a pizza e chama o ENTREGADOR;

O 5. ENTREGADOR pega a pizza e a entrega para VOCÊ na sua casa.

Nesse caso, todos os objetos: VOCÊ, ATENDENTE, PIZZAIOLO e ENTREGA-

DOR trabalharam juntos para alcançar o objetivo comum: entregar a pizza quentinha

na sua casa!

O paradigma da OO visualiza um sistema de software como uma coleção de

agentes interconectados (objetos). Cada objeto é responsável por realizar tarefas



específicas e é por meio da interação entre os objetos que uma tarefa computacional

é realizada.

Utilizar a OO para modelagem de sistemas diminui a diferença semântica entre

a realidade sendo modelada e os modelos construídos. A figura 42 ilustra a interação

entre os objetos.

Figura 42 – Interação entre os objetos

1.1 O princípio da abstração

Uma abstração é qualquer modelo que inclui os aspectos mais importantes e

essenciais de alguma coisa. As abstrações permitem gerenciar a complexidade e

concentrar a atenção nas características essenciais de um objeto.

Uma abstração é dependente da perspectiva: o que é importante em um con-

texto pode não ser importante em outro.

As principais características da abstração são:

Permite concentrar nos aspectos essenciais de uma aplicação;

Foca no que um objeto faz, antes de definir como implementá-lo.

Veja na figura 43 os conceitos que envolvem a abstração da OO.



Figura 43 – Princípios da OO

1.1.1 Encapsulamento

As principais características do encapsulamento são:

Forma de restringir o acesso ao comportamento interno de um objeto;

Ocultamento de informações;

Separa os aspectos externos de um objeto, que são acessíveis a outros ob-

jetos, dos detalhes internos da implementação, escondidos de outros objetos.

1.1.2 Polimorfismo

O polimorfismo é a capacidade de abstrair várias implementações diferentes

em uma única interface. Exemplo: o controle remoto da televisão também funciona

com o aparelho de DVD.

O polimorfismo garante que objetos semelhantes possuam interfaces diferen-

tes.

1.1.3 Herança

As principais características da Herança são:

Classes semelhantes são agrupadas em hierarquias;

Cada nível da hierarquia pode ser visto como um nível de abstração;

Cada classe em um nível da hierarquia herda as características das classes nos

níveis acima.

A figura 44 ilustra um exemplo de herança.



Figura 44 – Exemplo de Herança

1.1.5 Objetos

Os objetos estão em toda parte no mundo real:

Pessoas, Animais, Plantas, Carros, Aviões, Edifícios, Computadores, etc;

Todos os objetos têm atributos, por exemplo: tamanho, forma, cor e peso. E

todos exibem comportamento, por exemplo: uma bola rola, rebate, infla e murcha.

Diferentes objetos podem ter atributos semelhantes e podem exibir compor-

tamentos semelhantes. É possível fazer comparações, por exemplo, entre bebês e

adultos, e entre humanos e animais.

As principais características dos objetos são:

Objeto é uma entidade, uma coisa que possui um estado e um comportamento;

O estado de um objeto é caracterizado pelas suas variáveis (atributos);

O comportamento, pelas suas funções (métodos);

Cada objeto é único em seu escopo.

1.1.6 Estado dos Objetos

O estado de um objeto é definido pelas suas características internas, como

peso, altura e profissão para uma pessoa. Em uma linguagem de programação, es-

sas características são implementadas através de variáveis.



Na nomenclatura de OO, as variáveis de um objeto são chamadas de atribu-

tos.

1.1.7 Comportamento dos Objetos

O comportamento é definido pelas tarefas que um objeto é capaz de realizar,

como ler e escrever no caso de uma pessoa. As tarefas são implementadas através

de funções. As funções são chamadas de métodos em OO.

1.1.8 Objetos e Classes

Objetos afins são reunidos em categorias que descrevem suas características

comuns. Em OO, essas categorias são chamadas de classes. As classes são apenas

descrições de estados e comportamentos (abstração) e o objeto é criado por meio de

uma classe.

Exemplo: Planta da Casa é uma classe, a casa construída é o objeto.



Copyright © Tupy Virtual 2007

Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.

Autores: Rosemary Francisco

Elementos de Projetos de Informática: Material didático / Rosemary Francisco

Design institucional: Thiago Vedoi de Lima; Cristiane de Oliveira - Joinville: Tupy Virtual, 2007

Ficha catalográfica elaborada pela Biblioteca Universitária Tupy Virtual

Créditos

SOCIESC – Sociedade Educacional de Santa Catarina

Tupy Virtual – Ensino a Distância

Rua Albano Schmidt, 3333 – Joinville – SC – 89206-001Fone: (47)3461-0166E-mail: [email protected]: www.sociesc.org.br/portalead

Diretor GeralSandro Murilo Santos

Diretor de AdministraçãoVicente Otávio Martins de Resende

Diretor de Ensino, Pesquisa e ExtensãoRoque Antonio Mattei

Diretor do Instituto Superior TupyWesley Masterson Belo de Abreu

Diretor da Escola Técnica TupyLuiz Fernando Bublitz

Coordenador da Escola Técnica TupyAlexssandro FossileAlan Marcos Blenke

Coordenador do CursoJuliano Prim

Coordenador de ProjetosJosé Luiz Schmitt

Revisora PedagógicaNádia Fátima de Oliveira

EQUIPE TUPY VIRTUAL

Raimundo Nonato Gonçalves RobertWilson José MafraThiago Vedoi de LimaCristiane OliveiraJanae Gonçalves Martins

Design GráficoThiago Vedoi de Lima

Professor ResponsávelRosemary Francisco

EDIÇÃO – MATERIAL DIDÁTICO

Professor ConteudistaRosemary Francisco

Design InstitucionalThiago Vedoi de Lima

Cristiane Oliveira

Ilustração CapaThiago Vedoi de Lima

Projeto GráficoEquipe Tupy Virtual

Revisão OrtográficaNádia Fátima de Oliveira

Documents

Apostila Elementos de Projeto de Informática