Your SlideShare is downloading. ×
Apostila elementos de projeto de informática
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Apostila elementos de projeto de informática

222
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
222
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ELEMENTOS DE PROJETOS DE INFORMÁTICA EdiçÃo nº 1 - 2008 ROSEMARY FRANCISCO Apoio Gestão e Execução Conteúdo e Tecnologia
  • 2. 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
  • 3. Elementos de Projetos de Informática 3 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 4. Elementos de Projetos de Informática4 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 5. Elementos de Projetos de Informática 5 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 6. Elementos de Projetos de Informática6 SOCIESC - Sociedade Educacional de Santa Catarina Cronograma de Estudos Acompanhe no cronograma abaixo os conteúdos das aulas, e atualize as pos- síveis datas de realização de aprendizagem e avaliações. Semana Carga horária Aula Data/ Avaliação 1 4 Introdução a Projetos de Informática _/_ a _/_ 4 Introdução a UML _/_ a _/_ 8 Introdução a Ferramentas CASE _/_ a _/_ 2 8 Conhecendo os principais diagramas da UML _/_ a _/_ 8 Conhecendo o Processo de desenvolvimento de Software _/_ a _/_ 3 12 Modelando Projetos de Software _/_ a _/_ 4 Tendências do Processo de Engenharia de Software _/_ a _/_ 4 12 Estudo de Caso: Modelando um Projeto de Software _/_ a _/_
  • 7. Elementos de Projetos de Informática 7 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 8. Elementos de Projetos de Informática8 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 9. Elementos de Projetos de Informática 9 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 10. Elementos de Projetos de Informática10 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 11. Elementos de Projetos de Informática 11 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 12. Elementos de Projetos de Informática12 SOCIESC - Sociedade Educacional de Santa Catarina Figura 1 – Resultado do Chaos Research até o ano de 2002 Analisando a figura 1, podemos observar que a quantidade de projetos consi- 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.
  • 13. Elementos de Projetos de Informática 13 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 14. Elementos de Projetos de Informática14 SOCIESC - Sociedade Educacional de Santa Catarina çã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;
  • 15. Elementos de Projetos de Informática 15 SOCIESC - Sociedade Educacional de Santa Catarina • 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
  • 16. Elementos de Projetos de Informática16 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 17. Elementos de Projetos de Informática 17 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 18. Elementos de Projetos de Informática18 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 19. Elementos de Projetos de Informática 19 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 20. Elementos de Projetos de Informática20 SOCIESC - Sociedade Educacional de Santa Catarina 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 Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Modelagem de Software; • Introdução a UML; • UML e o Processo de Desenvolvimento de Software; • Exercícios propostos.
  • 21. Elementos de Projetos de Informática 21 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 22. Elementos de Projetos de Informática22 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 23. Elementos de Projetos de Informática 23 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 24. Elementos de Projetos de Informática24 SOCIESC - Sociedade Educacional de Santa Catarina 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á
  • 25. Elementos de Projetos de Informática 25 SOCIESC - Sociedade Educacional de Santa Catarina 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:
  • 26. Elementos de Projetos de Informática26 SOCIESC - Sociedade Educacional de Santa Catarina • 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”.
  • 27. Elementos de Projetos de Informática 27 SOCIESC - Sociedade Educacional de Santa Catarina 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;
  • 28. Elementos de Projetos de Informática28 SOCIESC - Sociedade Educacional de Santa Catarina • 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.
  • 29. Elementos de Projetos de Informática 29 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 30. Elementos de Projetos de Informática30 SOCIESC - Sociedade Educacional de Santa Catarina 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 é
  • 31. Elementos de Projetos de Informática 31 SOCIESC - Sociedade Educacional de Santa Catarina 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;
  • 32. Elementos de Projetos de Informática32 SOCIESC - Sociedade Educacional de Santa Catarina • 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. Exercícios Propostos 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.
  • 33. Elementos de Projetos de Informática 33 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 34. Elementos de Projetos de Informática34 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • 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 Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Introdução à Ferramenta CASE; • Utilizando Ferramenta CASE para Análise e Modelagem de um Projeto; • Exercícios propostos.
  • 35. Elementos de Projetos de Informática 35 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 36. Elementos de Projetos de Informática36 SOCIESC - Sociedade Educacional de Santa Catarina 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:
  • 37. Elementos de Projetos de Informática 37 SOCIESC - Sociedade Educacional de Santa Catarina • 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
  • 38. Elementos de Projetos de Informática38 SOCIESC - Sociedade Educacional de Santa Catarina 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;
  • 39. Elementos de Projetos de Informática 39 SOCIESC - Sociedade Educacional de Santa Catarina → 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.
  • 40. Elementos de Projetos de Informática40 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 41. Elementos de Projetos de Informática 41 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 42. Elementos de Projetos de Informática42 SOCIESC - Sociedade Educacional de Santa Catarina 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;
  • 43. Elementos de Projetos de Informática 43 SOCIESC - Sociedade Educacional de Santa Catarina 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; Figura 14 – Tela 2 da instalação da ferramenta Arquivo 1 Arquivo 1
  • 44. Elementos de Projetos de Informática44 SOCIESC - Sociedade Educacional de Santa Catarina 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; Figura 15 – Tela 3 da instalação da ferramenta 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; Figura 16 – Tela 4 da instalação da ferramenta 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; Figura 17 – Tela 5 da instalação da ferramenta
  • 45. Elementos de Projetos de Informática 45 SOCIESC - Sociedade Educacional de Santa Catarina 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; Figura 18 – Tela 6 da instalação da ferramenta 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. Figura 19 – Tela 7 da instalação da ferramenta 19. A instalação será iniciada conforme mostra a figura 20. Aguarde até o final da instalação.
  • 46. Elementos de Projetos de Informática46 SOCIESC - Sociedade Educacional de Santa Catarina Figura 20 – Tela 8 da instalação da ferramenta 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. Figura 21 – Tela 9 da instalação da ferramenta 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
  • 47. Elementos de Projetos de Informática 47 SOCIESC - Sociedade Educacional de Santa Catarina Síntese da Aula Nesta aula estudamos: • 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. Exercícios Propostos 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;
  • 48. Elementos de Projetos de Informática48 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 49. Elementos de Projetos de Informática 49 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • Enumerar os elementos da UML; • Identificar os principais diagramas UML; • Descrever o objetivo de cada diagrama. Conteúdos da Aula Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Elementos da UML; • Diagramas UML; • Exercícios propostos.
  • 50. Elementos de Projetos de Informática50 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 51. Elementos de Projetos de Informática 51 SOCIESC - Sociedade Educacional de Santa Catarina que proporciona valor para um determinado ator. Os itens comportamentais são considerados a parte dinâmica dos modelos da UML. Representam comportamentos no tempo e no espaço. São exemplos de itens comportamentais: • Mensagens – mostram as interações entre os objetos, classes; • Estados – definem os comportamentos que os objetos e classes podem as- sumir ao longo do sistema; • Ações – são as ações desempenhadas pelos objetos e classes do sistema. Os itens de agrupamento são as partes organizacionais dos modelos UML. Existe apenas um tipo principal de itens de agrupamento, os pacotes. Um pacote é um mecanismo que permite a organização dos itens estruturais e comportamentais. Por fim, os itens anotacionais são as partes explicativas dos modelos da UML. São os comentários incluídos nos modelos e que permitem descrever, esclarecer e/ou fazer alguma observação sobre qualquer elemento utilizado no modelo. A tabela 1 ilustra os elementos gráficos que representam os itens da UML. Tabela 1 – Itens da UML Classificação do Item Nome Figura Estrutural Classe Estrutural Interface Ou
  • 52. Elementos de Projetos de Informática52 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 53. Elementos de Projetos de Informática 53 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 54. Elementos de Projetos de Informática54 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 55. Elementos de Projetos de Informática 55 SOCIESC - Sociedade Educacional de Santa Catarina Tabela 2 – Tipos de Relacionamentos Nome Função Representação Dependência Relacionamento entre dois itens, a alteração no item independente pode afetar a semântica – funcio- namento – do item dependente. Elemento gráfico: seta aberta tracejada Exem- plo: Notação: • A classe Dependente depende estruturalmente da classe Independente. Associação Relacionamento estrutural entre classes que descrevem um con- junto de ligações, em que as liga- ções são conexões entre objetos que são instâncias das classes. A agregação é um tipo especial de associação, representando um relacionamento estrutural entre o todo e suas partes. Elemento gráfico: linha simples Exemplo: Notação: • Um departamento possui um ou mais funcioná- rios na sua hierarquia. Generaliza- ção Relacionamento de um elemento mais geral e outro mais especí- fico. Os objetos da classe-filha podem ser utilizados em qualquer lugar onde a classe-mãe ocorra, mas não o contrário. Elemento gráfico: seta fechada Exemplo: Notação: • A classe: Atleta é a classe-mãe. • As classes: Nadador e Tenista herdam a estru- tura – atributos e operações – da classe Atleta. Classes Asso- ciativas São classes ligadas a associa- ções, em vez de estarem liga- das a outras classes. Esse tipo de classe normalmente aparece quando duas ou mais classes estão associadas e é necessário manter informações sobre asso- ciação. Elemento gráfico: classe ligada a uma associa- ção por uma linha tracejada Exemplo: Classe associativa = Emprego
  • 56. Elementos de Projetos de Informática56 SOCIESC - Sociedade Educacional de Santa Catarina Os relacionamentos do tipo: Associação possuem ainda algumas caracterís- ticas que permitem um detalhamento maior no relacionamento entre duas classes. Estas características estão descritas na tabela 3. Tabela 3 – Características da Associação Caracterís- tica Função Representação Nome Uma associação pode ter um nome, que pode ser utilizado para descrever a natureza do relacio- namento. Papel Quando uma classe está em uma associação, possui um papel es- pecífico neste relacionamento. Multiplicidade É importante determinar a quan- tidade (multiplicidade) de objetos que podem ser conectados pela instância de uma conexão. A ta- bela 4 ilustra a simbologia para re- presentar as multiplicidades. Agregação É um tipo especial de associação que ilustra a associação todo/par- te. Toda ação realizada sobre a classe todo afetará as classes partes. Composição A composição é um tipo especial de agregação - agregação por va- lor. Semanticamente equivalente a um atributo. A remoção do todo implica na re- moção das partes e o acesso às partes é restrito ao todo. Significa que as classes/objetos indicadas como “partes” de uma composi- ção não estarão acessíveis ex- ternamente, somente por meio da classe/objeto “todo”. Classe Pessoa Classe Pessoa depois de utilizar composição
  • 57. Elementos de Projetos de Informática 57 SOCIESC - Sociedade Educacional de Santa Catarina Tabela 4 – Simbologia para representar multiplicidades Nome Simbologia Apenas um 1 Zero ou Muitos 0..* Um ou Muitos 1..* Zero ou um 0..1 Os diagramas de classes são utilizados para fazer a modelagem da visão estática de um sis- tema. Essa visão oferece principalmente suporte para os requisitos funcionais de um sistema – os serviços que o sistema deverá fornecer aos usuários finais (BOOCH, 2005, p. 109). As principais características dos diagramas de classes são: • Representar os dados e funções tratados pelo sistema; • Representar a forma como os dados serão armazenados de acordo com a orientação a objetos – classes e objetos; A figura 24 ilustra um exemplo de diagrama de classes de um sistema. Figura 24 – Exemplo de diagrama de classes Os requisitos funcionais e não- funcionais serão discutidos com mais detalhes nos capítulos 5 e 6.
  • 58. Elementos de Projetos de Informática58 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 59. Elementos de Projetos de Informática 59 SOCIESC - Sociedade Educacional de Santa Catarina Tabela 5 – Documentação de Caso de Uso Caso de Uso: Visualizar Avaliações Sumário: Aluno visualiza avaliação que recebeu – notas e freqüência – nas turmas de um semestre letivo. Ator Primário: Aluno Ator Secundário: Professor Pré-Condições: O aluno está identificado pelo sistema. Fluxo Principal: 1. O aluno solicita a visualização das avaliações para as disciplinas em que participou. 2. O sistema exibe os semestres letivos nos quais o aluno se inscreveu em pelo menos uma disciplina. 3. O aluno seleciona os semestres letivos cujas avaliações deseja visu- alizar. 4. O sistema exibe uma lista de avaliações agrupadas por semestres letivos selecionados e por turma. 5. O aluno visualiza as avaliações e o caso de uso termina. Fluxo de Exceção (2): Aluno sem inscrição 1. Não há semestre letivo no qual o aluno tenha participado em alguma disciplina. 2. O sistema reporta o fato e o caso de uso termina. Pós-Condições: O aluno obteve as avaliações que desejava visualizar. Fonte: BEZERRA, 2002, p. 82 A tabela 5 ilustra, de maneira geral, um modelo que pode ser utilizado para a documentação de casos de uso, mas como a UML não define um formato para a documentação textual, é importante conhecer a função de cada item utilizado na documentação exemplo e definir quais são os itens utilizados em seus projetos de software. A função de cada item, segundo Bezerra (2002, p. 66), pode ser identificada do seguinte modo: • Nome – é o nome do caso de uso. Cada caso de uso deve possuir um nome único que também deverá aparecer no diagrama de casos de uso. • Sumário – uma pequena descrição do caso de uso, funcionalidade. Deve ser breve e possuir no máximo duas frases. • Ator Primário – o nome do ator que inicia o caso de uso. • Ator Secundário – os nomes dos demais atores participantes do caso de uso, se existirem. • Pré-Condições – define as hipóteses que são assumidas como verdadeiras
  • 60. Elementos de Projetos de Informática60 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 61. Elementos de Projetos de Informática 61 SOCIESC - Sociedade Educacional de Santa Catarina A comunicação ou interação entre as funcionalidades do sistema – casos de uso – e os usuários do sistema – atores – é feita por meio dos relacionamentos. Os tipos de relacionamentos disponíveis para os diagramas de caso de uso são: • Comunicação – mais comumente utilizado. Faz a troca de informações entre o ator e o caso de uso. • Inclusão – disponível somente entre casos de uso. Utilizado quando dois ou mais casos de uso incluem uma seqüência comum de interações. • Extensão – é utilizado para modelar situações em que diferentes seqüências de interações podem ser inseridas em um caso de uso. Cada uma dessas se- qüências diferentes representa um comportamento opcional, que só ocorre sob certas condições ou dependendo da escolha do ator. • Generalização – é o mesmo conceito utilizado para as classes. Permite que um caso de uso (ou um ator) herde características de um caso de uso (ou ator) mais genérico. A tabela 6 ilustra os elementos gráficos utilizados em um diagrama de casos de uso. Tabela 6 – Elementos gráficos do diagrama de casos de uso Nome Representação Fronteira do Sistema Elemento gráfico: retângulo que agrupa os ca- sos de uso e os relacionamentos Ator Elemento gráfico: boneco palito Caso de Uso Elemento gráfico: elipse
  • 62. Elementos de Projetos de Informática62 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 63. Elementos de Projetos de Informática 63 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 64. Elementos de Projetos de Informática64 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 65. Elementos de Projetos de Informática 65 SOCIESC - Sociedade Educacional de Santa Catarina Os elementos gráficos do diagrama de estados estão ilustrados na tabela 7. Tabela 7 – Elementos gráficos do diagrama de estados Nome Representação Estado inicial do objeto Elemento gráfico: círculo preenchido Estado final do objeto Elemento gráfico: círculo elipsado Estado do objeto Elemento gráfico: retângulo arredondado Eventos / Ações – um evento é algo que aconte- ce em algum ponto do tempo e pode modificar o estado do objeto. Uma ação é uma operação que pode ser realizada pelo próprio objeto. Elemento gráfico: seta 2.6 Diagrama de atividades Um diagrama de atividade é essencialmente um gráfixo de fluxo, que exibe o fluxo de controle de uma atividade para outra. Ao contrário de um gráfico de fluxo tradicional, um diagrama de atividades mostra a concorrência, bem como as ramifica- ções de controle. Os diagramas de atividade são utilizados para fazer a modelagem de aspectos dinâmicos do sistema que envolve a modelagem das etapas seqüenciais – e possivel- mente concorrentes – em um processo do sistema de software. O diagrama de atividades irá representar os estados de uma atividade do sis- tema de software em formato de fluxo de dados. A figura 28 ilustra um exemplo de diagrama de atividade.
  • 66. Elementos de Projetos de Informática66 SOCIESC - Sociedade Educacional de Santa Catarina Figura 28 – Exemplo de diagrama de atividades Os elementos gráficos do diagrama de estados estão ilustrados na tabela 8. Tabela 8 – Elementos gráficos do diagrama de atividades Nome Representação Estado inicial da atividade Elemento gráfico: círculo preenchido Estado final da atividade Elemento gráfico: círculo elipsado Atores envolvidos na atividade Elemento gráfico: raias de natação Ação dos atores nas atividades Elemento gráfico: retângulo arredondado
  • 67. Elementos de Projetos de Informática 67 SOCIESC - Sociedade Educacional de Santa Catarina Decisão Elemento gráfico: losango Transição das Ações Elemento gráfico: seta Síntese da Aula Nesta aula estudamos: 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. Exercícios Propostos 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
  • 68. Elementos de Projetos de Informática68 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 69. Elementos de Projetos de Informática 69 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • 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 Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Introdução ao Processo de Desenvolvimento de Software; • Conhecendo os Modelos do Processo; • Exercícios Propostos.
  • 70. Elementos de Projetos de Informática70 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 71. Elementos de Projetos de Informática 71 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 72. Elementos de Projetos de Informática72 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 73. Elementos de Projetos de Informática 73 SOCIESC - Sociedade Educacional de Santa Catarina 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/
  • 74. Elementos de Projetos de Informática74 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 75. Elementos de Projetos de Informática 75 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 76. Elementos de Projetos de Informática76 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 77. Elementos de Projetos de Informática 77 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 78. Elementos de Projetos de Informática78 SOCIESC - Sociedade Educacional de Santa Catarina Síntese da Aula Nesta aula estudamos: 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. Exercícios Propostos 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;
  • 79. Elementos de Projetos de Informática 79 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 80. Elementos de Projetos de Informática80 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • 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 Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Análise e Projeto de Software; • Exercícios Propostos.
  • 81. Elementos de Projetos de Informática 81 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 82. Elementos de Projetos de Informática82 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 83. Elementos de Projetos de Informática 83 SOCIESC - Sociedade Educacional de Santa Catarina Nem sempre o usuário tem todas as informações que o analista necessita. Mui- tas vezes, o usuário tem informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim o analista deve sempre consultar outras pessoas além dos usuários da aplicação. A tabela 10 mostra um exemplo de questionário que pode ser aplicado em uma entre- vista com o usuário. Tabela 10 – Exemplo de Questionário Qual é o objetivo do Sistema?1. Que área vai atender?2. Que tipo e quantos usuários estarão interagindo com o sistema?3. Quais são as principais funcionalidades que o sistema deverá possuir?4. Quais funcionalidades os usuários poderão acessar?5. É necessário utilizar perfil de usuário para definir acesso aos usuários?6. Qual plataforma o sistema utilizará?7. Qual o banco de dados que irá utilizar?8. O sistema estará alocado dentro da empresa ou em um servidor de terceiro?9. Qual é o prazo de entrega?10. Necessita de uma equipe para o treinamento do Projeto?11. Há disponibilidade de alguém para acompanhar o desenvolvimento?12. Necessita treinamento no processo a ser sistematizado?13. Necessidade de alguma linguagem específica?14. Já há informações em arquivos ou banco de outros sistemas?15. Sistema terá integração com outros sistemas atuais?16. Há uma limitação de orçamento?17. Qual é a configuração padrão das máquinas da empresa(Windows 95,98,2000, XP ou Linux)?18. Haverá manutenção mensal no sistema?19. O sistema atenderá mais franquias da própria empresa?20. 1.3 Levantamento de Informações Requisitos são objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema. Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir para: 1. Que o usuário possa resolver um problema ou atingir um objetivo; 2. Ou atender às necessidades e/ou restrições da organização ou dos outros
  • 84. Elementos de Projetos de Informática84 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 85. Elementos de Projetos de Informática 85 SOCIESC - Sociedade Educacional de Santa Catarina dida que o tamanho e a complexidade do software aumentam. Os requisitos exercem influência uns sobre os outros. Por exemplo, o requisito de que o software deve ter grande portabilidade, ser implementado em Java para possibilitar o acesso por celu- lar, ou dispositivos móveis – pode implicar em que o requisito desempenho não seja satisfeito. O resultado final da análise e especificação de requisitos e das outras ativida- des da fase de definção deve ser apresentado aos clientes para que possam validá-lo. Esse documento oferece a concordância entre clientes, analistas e desenvolvedores sobre o que deve ser desenvolvido. É utilizando esse documento que as atividades da fase de desenvolvimento – codificação – serão validadas. Cada desenvolvedor utiliza um modelo específico para elaborar este documen- to. A sua estrutura, muitas vezes, depende do método que está sendo utilizado. Em linhas gerais, esse modelo deve ser basicamente textual, utilizando o mínimo de ter- mos técnicos, e ilustrados como modelos gráficos que demonstrem mais claramente a visão que os analistas tiveram dos problemas e dos requisitos para o futuro sistema. A tabela 11 ilustra uma lista de requisitos funcionais e não-funcionais de um sis- tema de software. A lista de requisitos se refere às informações levantadas para uma faculdade que necessita de aplicação para controlar processos acadêmicos como: vi- sualização de notas pelos alunos, cadastro de disciplinas, alocação de recursos para as turmas, etc. Tabela 11 – Lista resumida de requisitos # Descrição Tipo 1 O sistema deve permitir aos alunos visualizar as notas das disciplinas por semestre letivo. Requisito Funcional 2 O sistema deve permitir o lançamento das notas dos alu- nos por disciplina pelos professores. Requisito Funcional 3 O sistema deve permitir a abertura de turmas para uma disciplina, com a definição de sala e laboratórios a serem utilizados e dos horários e dias da semana em que haverá aulas. Requisito Funcional 4 O sistema deve ser desenvolvido para a plataforma WEB Requisito Não-Funcional
  • 86. Elementos de Projetos de Informática86 SOCIESC - Sociedade Educacional de Santa Catarina 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?
  • 87. Elementos de Projetos de Informática 87 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 88. Elementos de Projetos de Informática88 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 89. Elementos de Projetos de Informática 89 SOCIESC - Sociedade Educacional de Santa Catarina 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?
  • 90. Elementos de Projetos de Informática90 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 91. Elementos de Projetos de Informática 91 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 92. Elementos de Projetos de Informática92 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 93. Elementos de Projetos de Informática 93 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 94. Elementos de Projetos de Informática94 SOCIESC - Sociedade Educacional de Santa Catarina 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 Nesta aula estudamos: 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.
  • 95. Elementos de Projetos de Informática 95 SOCIESC - Sociedade Educacional de Santa Catarina Exercícios Propostos 1) Analise os requisitos abaixo e desenvolva as seguintes atividades: a) Identificação dos Atores do Sistema; b) Identificação dos Casos de Uso do Sistema; c) Elaboração do Diagrama de Casos de Uso; d) Identificação das Classes do Sistema; e) Elaboração do Diagrama de Classes. # Descrição Tipo 1 O sistema deve permitir ao Funcionário ca- dastrar Clientes contendo os dados: nome, endereço, e telefone Requisito Funcional 2 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
  • 96. Elementos de Projetos de Informática96 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • Identificar as principais tendências para o desenvolvimento e gerenciamento de projetos de software. Conteúdos da Aula Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • A importância do Software; • Metodologias Ágeis; • Exercícios Propostos.
  • 97. Elementos de Projetos de Informática 97 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 98. Elementos de Projetos de Informática98 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 99. Elementos de Projetos de Informática 99 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 100. Elementos de Projetos de Informática100 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 101. Elementos de Projetos de Informática 101 SOCIESC - Sociedade Educacional de Santa Catarina 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 Nesta aula estudamos: 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.
  • 102. Elementos de Projetos de Informática102 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 103. Elementos de Projetos de Informática 103 SOCIESC - Sociedade Educacional de Santa Catarina 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 Ao final desta aula, você deverá ser capaz de: • Desenvolver as principais atividades de modelagem de software; • Elaborar os diagramas UML com a ferramenta JUDE. Conteúdos da Aula Acompanhe os conteúdos desta aula. Se você preferir, assi- nale-os à medida em que for estudando. • Definição do Estudo de Caso e elaboração dos modelos de software.
  • 104. Elementos de Projetos de Informática104 SOCIESC - Sociedade Educacional de Santa Catarina 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:
  • 105. Elementos de Projetos de Informática 105 SOCIESC - Sociedade Educacional de Santa Catarina • Funcionais – diretamente ligados à funcionalidade do software, descrevem as funções que o software deve executar; • Não-Funcionais – expressam condições que o software deve atender ou qualidades específicas que o software deve ter. Os requisitos identificados para o software do estudo de caso proposto, podem ser visualizados na tabela 12. Tabela 12 – Requisitos do sistema do estudo de caso # Descrição Tipo 1 O sistema deve permitir que o gerente cadastre salões de festas Requisito Funcional 2 O sistema deve permitir que o gerente cadastre pro- fissionais Requisito Funcional 3 O sistema deve permitir que o gerente realize o cadas- tro de serviços utilizados em uma festa de casamento, como buffet e carros utilizados Requisito Funcional 4 O sistema deverá permitir que o cliente realize o ca- dastro da lista de convidados Requisito Funcional 5 O sistema deverá permitir que o cliente elabore a con- figuração da festa Requisito Funcional 6 O sistema deverá permitir a geração do orçamento para o cliente Requisito Funcional 7 O sistema deverá permitir que o gerente realize a im- pressão de relatório de festas Requisito Funcional 8 O sistema deverá permitir que o cliente cadastre a lista de presentes Requisito Funcional 9 O sistema deverá permitir que o gerente realize o ca- dastro de usuários Requisito Funcional 10 O sistema deverá permitir a autenticação dos usuá- rios Requisito Funcional 11 O sistema deve ser compatível com os navegadores Internet Explorer e Firefox Requisito Não-Funcional 12 O sistema deve garantir que o tempo de retorno das consul- tas seja inferior a 5 segundos Requisito Não-Funcional
  • 106. Elementos de Projetos de Informática106 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 107. Elementos de Projetos de Informática 107 SOCIESC - Sociedade Educacional de Santa Catarina Tabela 13 – Especificação do Caso de Uso: Autentica Usuário Caso de Uso: Autentica Usuário Sumário: Efetuar o login dos usuários no sistema de acordo com o perfil de cada um e exibir as telas permitidas para cada perfil. Ator Primário: Gerente Ator Secundário: Cliente Pré-Condição: Usuário acessa o sistema Fluxo Principal: 1. O sistema apresenta formulário contendo as informações: Login e Senha, além das opções: Entrar e Cancelar. 2. Usuário informe os dados e seleciona a opção: Entrar [A1]. 3. O sistema verifica a autenticidade dos dados informados pelo usuá- rio [A2]. 4. O sistema autentica o usuário e apresenta a tela com as opções que ele pode acessar. 5. Caso de uso é encerrado. Fluxo Alternativo: A1. Usuário seleciona a opção: Cancelar a. Caso de Uso é encerrado A2. Login ou senha inválida a. O sistema apresenta a mensagem: “Usuário ou senha inválido” e a opção: OK. b. O usuário seleciona a opção OK. c. O caso de uso retorna para o passo 2 do fluxo principal. 1.4 Elaborando Diagrama de Casos de Uso Após a identificação dos atores e os casos de uso, é possível elaborar o dia- grama de casos de uso que irá ilustrar a relação dos atores com as funcionalidades do sistema – casos de uso do sistema. A figura 39 ilustra o modelo de diagrama de casos de uso proposto para o estudo de caso. Figura 39 – Diagrama de Casos de Uso do Estudo de Caso
  • 108. Elementos de Projetos de Informática108 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 109. Elementos de Projetos de Informática 109 SOCIESC - Sociedade Educacional de Santa Catarina 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-
  • 110. Elementos de Projetos de Informática110 SOCIESC - Sociedade Educacional de Santa Catarina 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
  • 111. Elementos de Projetos de Informática 111 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 112. Elementos de Projetos de Informática112 SOCIESC - Sociedade Educacional de Santa Catarina 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/
  • 113. Elementos de Projetos de Informática 113 SOCIESC - Sociedade Educacional de Santa Catarina APÊNDICE 1 1 O PARADIGMA DA ORIENTAÇÃO A OBJETOS Um paradigma é a forma de abordar um problema. Alan Kay, um dos pais do paradigma da orientação a objetos, imaginou o funcionamento do sistema de software como o de um ser vivo. Nesse sistema, cada “célula” interagiria com outras células por meio de mensagens para realizar um objetivo comum. Alan Kay pensou em construir um sistema de software a partir de agentes autô- nomos (atuais objetos) que interagem entre si. Assim, foram estabelecidos os seguin- tes princípios da orientação a objetos: Qualquer coisa é um objeto; Objetos realizam tarefas por meio da requisição de serviços a outros objetos; Cada objeto pertence a uma determinada classe; Uma classe agrupa objetos similares; A classe é um repositório para comportamento associado ao objeto; Classes são organizadas em hierarquias. Exemplo da utilização dos princípios da OO: Para comprar uma pizza1. VOCÊ que está muito ocupado, pede sua pizza por tele- fone; VOCÊ2. informa ao ATENDENTE seus dados e as características da pizza que de- seja comprar; O3. ATENDENTE atende sua solicitação e comunica ao PIZZAIOLO seu pedido; O4. PIZZAIOLO faz a pizza e chama o ENTREGADOR; O5. ENTREGADOR pega a pizza e a entrega para VOCÊ na sua casa. Nesse caso, todos os objetos: VOCÊ, ATENDENTE, PIZZAIOLO e ENTREGA- DOR trabalharam juntos para alcançar o objetivo comum: entregar a pizza quentinha na sua casa! O paradigma da OO visualiza um sistema de software como uma coleção de agentes interconectados (objetos). Cada objeto é responsável por realizar tarefas
  • 114. Elementos de Projetos de Informática114 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 115. Elementos de Projetos de Informática 115 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 116. Elementos de Projetos de Informática116 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 117. Elementos de Projetos de Informática 117 SOCIESC - Sociedade Educacional de Santa Catarina 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.
  • 118. Elementos de Projetos de Informática118 SOCIESC - Sociedade Educacional de Santa Catarina Copyright © Tupy Virtual 2007 Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição. Autores: Rosemary Francisco Elementos de Projetos de Informática: Material didático / Rosemary Francisco Design institucional: Thiago Vedoi de Lima; Cristiane de Oliveira - Joinville: Tupy Virtual, 2007 Ficha catalográfica elaborada pela Biblioteca Universitária Tupy Virtual Créditos SOCIESC – Sociedade Educacional de Santa Catarina Tupy Virtual – Ensino a Distância Rua Albano Schmidt, 3333 – Joinville – SC – 89206-001 Fone: (47)3461-0166 E-mail: ead@sociesc.org.br Site: www.sociesc.org.br/portalead Diretor Geral Sandro Murilo Santos Diretor de Administração Vicente Otávio Martins de Resende Diretor de Ensino, Pesquisa e Extensão Roque Antonio Mattei Diretor do Instituto Superior Tupy Wesley Masterson Belo de Abreu Diretor da Escola Técnica Tupy Luiz Fernando Bublitz Coordenador da Escola Técnica Tupy Alexssandro Fossile Alan Marcos Blenke Coordenador do Curso Juliano Prim Coordenador de Projetos José Luiz Schmitt Revisora Pedagógica Nádia Fátima de Oliveira EQUIPE TUPY VIRTUAL Raimundo Nonato Gonçalves Robert Wilson José Mafra Thiago Vedoi de Lima Cristiane Oliveira Janae Gonçalves Martins Design Gráfico Thiago Vedoi de Lima Professor Responsável Rosemary Francisco EDIÇÃO – MATERIAL DIDÁTICO Professor Conteudista Rosemary Francisco Design Institucional Thiago Vedoi de Lima Cristiane Oliveira Ilustração Capa Thiago Vedoi de Lima Projeto Gráfico Equipe Tupy Virtual Revisão Ortográfica Nádia Fátima de Oliveira