Desenvolvendo softwares Orientados a Objeto

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (4)  (1)

Veja neste artigo o modelo cascata e o modelo espiral para desenvolvimento de sistemas.

 

Olá pessoal,

 

Em primeiro lugar quero pedir desculpas pela demora na publicação na coluna, pois tive alguns problemas de ordem pessoal e terminei atrasando o material. Em segundo lugar, hoje decidi escrever sobre algo completamente diferente, porém fundamental. Decidi escrever sobre Modelos O.O.

 

Existem vários modelos para a definição do ciclo de vida de produção de software, mas quero nortear-me por apenas dois desses modelos que considero fundamentais na produção: o modelo espiral e o modelo cascata(waterflow).

 

Vou tentar resumir de maneira bem simples os dois modelos.

 

Primeiro vamos entender o que é um ciclo de vida de produção de software.

 

Os modelos de ciclo de vida de produção de software representam mais do que o ciclo de produção, representam também a filosofia e a alma da empresa, bem como o tipo de produto que essa fábrica de software produz.

 

O modelo cascata representa uma produção mais conservadora, e agora vou um pouco além. Certamente isto será motivo de brigas e repreensões. Alguns autores colocam esse modelo como um modelo de produção ultrapassado, e hoje existem variações um tanto equivocadas deste modelo. O desenho abaixo representa a versão do modelo que eu considero a que mais representa a idéia deste modelo.

 

mod00fig01.JPG 

 

Como vemos na figura acima, a produção de software está dividida em 5 (cinco) etapas, e para melhor entender o modelo, vamos fazer uma analogia com a construção civil. Pense em uma construção de um prédio em um determinado bairro.

 

  • A primeira etapa consiste em ver os requisitos do sistema, no caso do prédio, os requisitos de todo o projeto, desde a infra-estrutura do bairro passando pela clientela-alvo e chegando até o plano de venda.
  • A segunda etapa representa os requisitos do software, no caso do prédio, seria algo como os requisitos da construção, deste o alicerce do prédio até a parte elétrica, segurança, paisagismo, o quanto vou gastar de canos, tintas, tijolos, cimentos, etc.
  • A terceira etapa é o design do sistema, são os modelos, no caso da construção civil, seria desde a maquete até o apartamento decorado, é a previsão de como o projeto vai ficar.
  • A quarta etapa é a codificação: esta é a hora de programar e, no nosso exemplo de construção civil, equivale à hora de assentar tijolos.
  • A quinta etapa são os testes. Vamos garantir o que está feito, no caso da construção civil, chegou a hora de ver se as tomadas estão funcionando, se existe água em todos os pontos de água, etc.
  • E a última etapa é o lançamento, pronto, agora é só reproduzir em larga escala e vender o produto.

Mais do que o ciclo de produção, esse modelo representa um sistema seguro, algo que só chega a ser lançado depois de testado. Podemos perceber que na etapa de teste ele gera duas alimentações, uma que representa o lançamento do sistema, e outra que vai literalmente ao sentido contrário representando a correção de algum erro. Note que neste caso, o erro é informado diretamente ao topo do processo, pois caso o problema não tenha sido gerado lá, houve algum erro de entendimento do sistema, pois uma etapa gera dados para outra etapa.

 

Voltemos ao nosso exemplo de construção civil. Quem vai definir os padrões de segurança do empreendimento não será o pedreiro na hora de construir o muro, já que isso vem definido desde a etapa de requisitos do sistema.

 

Acho que deu para entender, e talvez seja melhor eu parar por aqui, caso contrário vou me estender até onde não devo. Voltarei a escrever sobre isso futuramente.

 

O outro modelo é o espiral.

 

mod00fig02.JPG 

 

No modelo espiral o processo é mais dinâmico. Na primeira etapa é uma certa “mistura” da análise de requisitos de sistemas e de software. Já a segunda etapa consiste no designer, ou seja, a modelagem de dados. Seguido do modelo construído, vem a programação e é ao final da programação que o produto é lançado para que então possa ser testado e, finalmente, possa realimentar o sistema.

 

Não entendeu?

 

Tentarei exemplificar, pense na maioria dos produtos Microsoft. Quem testa esses produtos?

 

Na maioria das vezes somos nós quem testamos. A partir daí geramos um relatório de erros que irão alimentar a próxima versão, ou melhor, que estarão corrigidos no próximo service-pack, e assim sucessivamente até que a correção do produto se torne inviável e seja lançado um novo produto.

 

Alguns autores defendem a idéia de que esse modelo é o mais atual e defendem a utilização deste tipo de desenvolvimento. Eu fico em cima do muro e digo que não existe melhor, existem situações onde um é melhor que o outro, por exemplo, eu não entraria em um avião cujo sistema de pouso fosse desenvolvido em espiral, imagina a fala, “olha, acabamos de desenvolver, se der algum erro na próxima versão isso será arrumado”.

 

Mas agora que começo o artigo.

 

O que isso tem a ver com a programação em si? Ou melhor, o que isso tem a ver com Java?

 

Bom, demonstrei esses dois modelos só para fazer uma pergunta aos senhores, queridos leitores: nos dois modelos, a etapa de codificação vem antes ou depois da etapa de modelagem (Designer)?

 

Vem depois.

 

Então, qual é o motivo de na maioria das vezes não documentarmos de maneira mínima o nosso sistema? O que nos leva a ver o desenvolvimento de software como mera programação? Estudos mostram que o tempo relativo à programação de um sistema é de apenas 20% do tempo total de desenvolvimento, o resto do tempo está dividido nas demais etapas do processo.

 

Todos nós conhecemos diversos kits visuais que terminam fazendo o trabalho do programador quase que completo. O programador termina resumindo a sua tarefa em clicar e arrastar um ou outro código, quando necessário.

 

A idéia é tentar alertá-los para a possibilidade de aprender documentar, pois em minha experiência como professor de técnicas de programação, somente após entender um modelo O.O. um programador poderá programar em O.O.

 

E para isso, vão algumas dicas legais.

 

Classe – representa um conjunto de objetos, logo é de bom tom que seu nome esteja no plural, a mesma coisa serve para tabela do banco de dados.

 

Objeto – algo construído a partir de uma Classe, logo é de bom tom que seu nome esteja no singular.

 

Métodos – definem ação de uma classe, logo é de agrado o uso de verbos.

 

Atributos – São as características de uma classe, logo é de bom tom o uso de nomes compostos.

 

Vamos pensar em um exemplo meramente didático. A Classe Circulos (sem acento pois nome de classe, assim como de tabela em banco não deve ter acentos.)

        

Nome da Classe: Circulos

Nome de objetos construído pela classe: bola, circulo, lente, circunferencia, etc

Nome de atributos da classe: raio, cor, espessuraLinha, etc.

Nome de métodos: desenhar(), calcularArea(), getRaio().

        

O exemplo, apesar de meio sem graça, mostra o início de algum tipo de documentação. Eu sou um pouco mais radical e coloco nomes enormes nos meus métodos e atributos, algo como: raioDoCirculo no lugar de raio, mas esse é um costume bobo e sem sentido que procuro melhorar.

 

O interessante é que a chamada de métodos para futuros objetos da classe fique simples e clara, bola.desenhar() por exemplo, sendo até mesmo indutiva.

 

Bom, agora vamos à novidade da coluna, estou preparando o material para futura publicação no Portal Devmedia onde irei tratar de Orientação ao Objeto em todas as etapas do processo de confecção de software, e na próxima coluna mostrarei como encontrar futuras classes e métodos durante a primeira etapa da elaboração de um software.

 

http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.html

 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?