Modelos Evolucionários

Dando continuidade a explanação sobre modelos prescritivos de software, iremos nesse post falar sobre os modelos evolucionários de desenvolvimento de software.

Como o próprio nome já sugere os modelos explanados aqui são explicitamente projetados para acomodar um produto que evolui com o tempo.

A cada iteração, os modelos evolucionários tem por objetivo produzir uma versão melhor e mais completa do software.

Vamos a eles:

Modelo de Prototipagem

A prototipação é uma ferramenta que pode ser usada em qualquer um dos modelos apresentados até agora

Essa técnica auxilia o engenheiro de software e o cliente aentenderem melhor o que deve ser construído quando os requisitos estão confusos.

Um protótipo é uma espécie de versão preliminar do software.Pode ser um programa ou no papel e concentra-se na representação dos aspectos dosoftware que são visíveis para o cliente.





Modelo Espiral

O modelo espiral é uma evolução dos modelos vistos anteriormente valorizando os pontos positivos desses modelos e desprezando o pontos negativos.

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.

Na segunda tarefa, avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto.

Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata.

Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.


Bom gente, acho que já falamos muito sobre os modelos prescritivos de desenvolvimento? Nos próximos posts vamos falar um pouco sobre um processo de desenvolvimento de software muito difundido no mercado - O RUP.

Inté!

Modelos prescritivos de desenvolvimento de software

Na Engenharia de Software, processo é um conjunto de passos parcialmente ordenados, cujo objetivo é atingir uma meta: entregar um produto de software de maneira eficiente, previsível e que atinja as necessidades de negócio. Geralmente inclui "atividades" como análise de requisitos, programação, testes, entre outras tarefas. Conlui-se portanto que um processo é composto por atividades relacionadas e os modelos servem para dar uma visão de como é um processo. Um modelo de processo de software define o que deve ser realizado em cada fase do desenvolvimento e dá as instruções de como realizar essas atividades. Ele serve como um guia, um roteiro para a execução de um processo de desenvolvimento. Um modelo descritivo retrata como um processo é executado em um ambiente em particular. Já um "modelo prescritivo" retrata como um processo deveria ser executado. Sendo assim um modelo prescritivo é uma espécie de recomendação que pode ser adaptada ou melhorada (veja os modelos de melhoria de processo CMMI e SPICE) pela empresa de software que for adotá-la. Esses modelos abrangem três elementos principais:

• Processos: determinam quais são as tarefas necessárias e em que ordem elas devem ser executadas.

• Métodos: fornecem detalhes fundamentais de como fazer para executar as tarefas necessárias.

• Ferramentas: proporcionam apoio automatizado ou semi-automatizado aos processos e métodos.

Existem um conjunto de atividades que aparecem na maioria dos modelos de processos prescritivos de software, diferindo-se apenas com relação ao fluxo de trabalho. São elas:

1. Comunicação: levantamento de requisitos em colaboração com o cliente.
2. Planejamento: estabelece as tarefas, os riscos, os recursos, os produtos e um cronograma.
3. Modelagem: criação de modelos que permitam ao desenvolvedor entender melhor o projeto e seus requisitos. Ações: Análise – modelos de especificação de requisitos e Projeto – modelos de especificação de projeto.
4. Construção: geração de código e testes.
5. Implantação: entrega do software ao cliente.

Bom, mas vamos deixar de bla bla bla e falar do que realmente interessa - Os modelos prescritivos de desenvolvimento. MODELO EM CASCATA O modelo em cascata é o modelo prescrito mais antigo e por isso é considerado um modelo clássico. Ele sugere uma abordagem sequencial para as atividades do processo. Projetos reais raramente seguem o fluxo seqüencial, pois é difícil estabelecer todos os requisitos inicialmente e por conta disso o modelo em cascata possui uma série de limitações ou desvantagens:

• Uma versão executável do software só fica disponível no final do processo.
• Nesse modelo ocorrem o que chamamos de estados de bloqueio: membros da equipe ficam esperando outros membros terminarem a sua parte.
• É adequado quando os requisitos são bem entendidos, como em aperfeiçoamentos de um sistema existente.

MODELO INCREMENTAL O modelo incremental pode ser considerado uma evolução do modelo em cascata. Este modelo é composto pelas atividades do modelo em cascasta porém estas atividades são realizadas repetidamente, ou seja, de forma iterativa. Cada seqüência produz incrementos do software passíveis de serem entregues, fornecendo assim, progressivamente mais funcionalidade ao primeiro incremento que é chamado de núcleo de produto. Esse modelo é particularmente útil quando não há mão-de-obra/recursos disponíveis para uma implementação completa. MODELO RAD (Rapid Application Development) No caso da equipe ser grande, um modelo possível é o modelo RAD. Ele é recomendável quando uma aplicação pode ser modularizada. Desvantagens do modelo RAD:

• Exige pessoal suficiente para criar várias equipes RAD.
• Desenvolvedores e clientes têm que estar comprometidos com atividades rápidas.
• Exige que o sistema seja modularizável.

No próximo post falaremos sobre outros modelos. Abs, HUGO

Análise Orientada a Objeto

Uma das principais atividades de um analista é a análise de um problema e a modelagem conceitual de soluções na forma de sistemas. Para isto, o analista se utiliza de ferramentas e técnicas de apoio de modo a aumentar eficiência e a eficácia na produção de software.

Como o nome já sugere, a modelagem compreende a produção de modelos capazes de descrever a solução proposta pelo analista de forma conceitual. Deste modo, é possível se promover a comunicação entre o analista e o cliente que encomendou o produto de software em questão.

Conforme citado no post anterior, a análise estruturada e essencial faz uso dos diagramas de contexto, de diagramas de fluxo de dados e de diagramas de entidade e relacionamento. A modelagem orientada a objetos se utiliza de modelos constantes na UML, mas esse assunto merece um post a parte.

O primeiro passo para se aprender a modelar um sistema orientado a objeto é conhecer o que chamamos de paradigma da orientação a objetos. Entende-se por paradigma a representação de um padrão a ser seguido, um modo de se pensar sobre, encarar algo ou agir de acordo com algum contexto. Profundo não! Sem frescura, é conhecer os conceitos dos elementos que constitui a Orientação a objetos (classes, objetos, herança, polimorfirmo, encapsulamento entre outros).

Bom então "bora começar do começo"

Objetos

Boa parte de nosso entendimento e relacionamento com o mundo se dá por meio do conceito de objetos. Ao observarmos as coisas ou seres que existem ao nosso redor, há uma tendência natural de tentarmos identificar o que são essas diferentes entidades, ou seja, como aparentam ser e que comportamento tem.

Um carro possui em comum quatro rodas e tem como comportamento se locomover. Apesar de possuir características comuns, os objetos possuem características que os identificam de forma única. O número de chassi de um carro nunca se repete por exemplo. São estas características que definem o "estado" a identidade do objeto.

Classes

Já as características comuns como cor, potencia, quantidade de lugares, etc nos permitem categorizar /agrupar/ "classificar" os objetos em conjuntos. A esses conjuntos damos o nome de classes. É natural para facilitarmos nosso entendimento, criarmos uma classificação para as coisas que embora seja distintas possuem características comuns.

Na pratica, podemos definir uma classe como sendo uma estrutura que uni as variáveis e os procedimentos presentes em um programa.

Podemos dizer que um objeto é uma "instância" de uma classe.

Uma classe é uma estrutura composta por atributos (características) e métodos (comportamentos).

Quando instanciamos um objeto de uma classe, atribuímos valores iniciais aos atributos desse objeto através de um método especial chamado de método construtor Para limpar esse objeto da memória principal do computador utilizamos o método conhecido como destrutor.

Encapsulamento

O encapsulamento indica que podemos utilizar um objeto conhecendo apenas a sua interface, isto é, sua aparência exterior sem conhecer seu funcionamento interior. Por exemplo, você envia ordens a um carro quando o está dirigindo sem precisar conhecer o que rola "por trás dos bastidores". Quando você liga um carro que atividades esse carro realiza para atender a este comando!

O estado de um objeto só pode ser alterado através de seus comportamentos visíveis.

Os membros de uma classe (atributos e métodos) possuem indicadores de visibilidade conhecidos como modificadores de acesso. Através deles, determinamos o nível de acesso desses membros.

Um membro privado só pode ser visualizado pela classe que o contém.

Um membro protegido só pode ser acessado pela classe que o contém e por classes que herdam esses membros.

Um membro público pode ser acessado por qualquer classe.

Os valores dos atributos de um objeto devem ser modificados através de seus métodos públicos, ou seja, através de seus "métodos setadores".

Um método definido como estático pode ser invocado sem a necessidade de se instanciar um objeto da classe.


Herança

A herança é o mecanismo que permite a criação de classes mais específicas a partir de classes mais genéricas. É esse paradigma que promove a reutilização ou reaproveitamento de caracteríscas e comportamentos.

Um carro de passeio e um utilitário são classes mais específicas que possui características comuns herdadas de uma classe mais genérica - a classe carro.

No final das contas a herança acaba criando uma hierarquia entre classes mais genéricas(superclasses) e classes mais especializadas (subclasses).

Cabe aqui falar de outros modificadores de acesso.

Classes abstratas que não podem ser instanciadas podendo apenas ser herdadas.

Classes finais não podem ser herdadas.

Os métodos abstratos são aqueles que são declarados numa superclasse e implementados em suas subclasses.

Uma interface é uma estrutura que contem apenas a assinatura de métodos, porém o contéudo desses métodos é escrita nas classes que implementam essa interface.

Polimorfismo

A palavra polimorfismo sugere o conceito de várias formas. Esse paradigma nos permite redefinir comportamentos. Todo carro possui o comportamento "passar marcha" , entretanto um carro com câmbio automático realiza essa tarefa de maneira diferente de um carro com câmbio mecânico.

Na programação orientada a objeto o polimorfismo é promovido através da sobrecarga e da sobrescrita de métodos.

A Sobrescrita refere-se apenas a metodos das classes filhas. É o ato de mudar o comportamento de um método em uma subclasse.

A Sobrecarga refere-se tanto a mesma classe quanto a classe filha. É o ato de ter-se mais de um método com o mesmo nome, porém com lista de parâmetros diferentes, ou seja, com assinaturas distintas.

Não existe sobrescrita em métodos da mesma classe, isso não faz sentido. Por outro lado existe sobrecarga, facilitando o programador com sua API.

Métodos finais não podem ser sobrescritos.

Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento ( métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. Esses objetos se comunicam através da troca de mensagens, ou seja, atráves da solicitação de serviços.

Bom, tentei aqui explanar uma série de conceitos importantes. No próximo post vou falar sobre UML.

Análise Estruturada X Essencial

Eu diria que a análise de sistema é composta de uma série de técnicas e ferramentas que tem por objetivo auxiliar ao analista de sistemas na tarefa de modelagem.

Uma das ferramentas preferidas dos Analistas são os diagramas, que possibilita ser ter uma visão conceitual de como o sistema funcionará. Afinal, uma imagem fala mais do que mil palavras.

O modelo de análise estruturada formalizado na década de 70 e popularizado principalmente por [GANE,1983] e [DeMARCO,1989]. foi e ainda é bastante utilizada por analistas de sistemas para criar uma visão conceitual dos sistemas.

Fundamentada no princípio da decomposição funcional, ele tem como objetivo a modelagem utilizando-se, para esse fim, de um conjunto de ferramentas, sendo o Diagrama de Fluxo de Dados (DFD) e o Dicionário de Dados (DD) as principais delas.

O método de decomposição recomendado é baseado na busca pela menor taxa de transferência de dados entre os sub-processos dos processos que estão sendo analisados, o que levaria, por conseqüência, a um modelo da organização decomposta em módulos funcionalmente coesos, ou seja, módulos que têm uma única função.

A principal crítica à análise estruturada é a não replicabilidade dos requisitos resultantes da análise, caso fosse feito um experimento em que diversos analistas fossem incumbidos de analisarem o mesmo sistema. Isso porque o processo de decomposição utilizado depende da abordagem de cada analista particularmente (dos seus pressupostos e de suas experiências anteriores ao projeto em questão) e das coincidências de informações oriundas das pessoas que compõem a organização social sob análise.

Além disso, a grande quantidade de artefatos produzidos tornavam o projeto muito volumoso.

A Análise Essencial de Sistemas pode ser considerada uma evolução da análise estruturada.

A abordagem da análise essencial de sistemas utiliza-se das mesmas ferramentas de modelagem da análise estruturada, mas os mecanismos são diferentes. Ao invés de uma decomposição do mais geral para o mais específico ("top-down") o método prevê que sejam identificados, inicialmente, os eventos externos aos quais espera-se que a organização social em questão responda, sendo derivadas então as ações (ou funcões) em resposta a esses eventos e, posteriormente, os eventos gerados internamente e também as respectivas ações.

A expressão "essencial" deve-se ao fato de que não serão consideradas quaisquer restrições tecnológicas, ou seja, como se a tecnologia disponível fosse perfeita o suficiente para suportar quaisquer questões relacionadas à captura ou mixagem dos dados, permitindo que seja possível concentrar-se somente sobre as questões essenciais do sistema sob análise.

Com a evolução dos paradigmas de programação e consequentemente com a evolução das linguagens voltadas para o desenvolvimento de sistemas, novas técnicas e modelos foram criados possibilitando ao analista prover vários tipos de visão sobre os sistemas. Essa evolução promoveu o surgimento da UML, padrão altamente difundido e aceito pelo mercado. Próximo passo: O paradigma da programação Orientada a Objetos e a UML.

Vamos que vamos!

A Engenharia de software

Toda ciência possui áreas de conhecimento e na computação a questão não poderia ser diferente.

A Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos e outras disciplinas, objetivando organização, produtividade e qualidade.

Os fundamentos científicos para a engenharia de software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades.

Além disso, a engenharia de software oferece mecanismos para se gerenciar o processo de desenvolvimento de um sistema de informação.

A esses mecanimos damos o nome de metodologias de desenvolvimento de software. Uma metodologia de software é composta por uma sequência de atividades com a finalidade de produzir produtos de software de qualidade. Esse conjunto de atividades é conhecido como ciclo de vida do processo.

Existem uma série de modelos de processos de desenvolvimento, ou seja, uma série de ciclos de vida consagrados na Engenharia de Software. Cabe aqui citar os modelos de ciclo de vida em cascaca e o modelo espiral.

Outro assunto que não podemos deixar de mencionar é que a evolução dos paradigmas de programação promoveram uma evolução na modelagem de sistemas. Uma prova disso é o surgimento da análise estruturada, depois da análise essencial e mais tarde da análise orientada a objetos.

Nos próximos posts pretendo escrever mais a respeito desses assuntos.

Evolução dos paradigmas de programação

Existe um ditado que diz “Quem não aprende com o passado está fadado a repeti-lo”, assim é importante contarmos aqui uma historinha sobre a evolução da programação de computadores.

Como se sabe, um processador de computador só entende o que é zero e um, ou seja, uma CPU só consegue interpretar a linguagem binária.

Nos primórdios da computação, a única alternativa para se programar um computador era jogar o código binário de programas na memória principal do computador. A probabilidade de erros era grande, a manutenção de código era impossível e o reuso um sonho distante. Essa abordagem é conhecida como programação binária.

Para resolver essas questões surgem as primeiras linguagens de programação e conseqüentemente os compiladores (responsáveis pela conversão da linguagem natural em linguagem de máquina). Com estas linguagens era possível se criar programas com estruturas monolíticas responsáveis por executar todas as tarefas de um programa.

Nasce a programação linear. A manutenção desses programas não era tarefa simples e seu código era praticamente ilegível, dificultando até o planejamento da uma solução de um problema utilizando programas deste tipo.

Era preciso dividir para conquistar. Foi com o surgimento de linguagens de programação capazes de representar o conceito de procedimentos que se resolveu esse problema.

Surge então o conceito programação procedural que permitiu a divisão do código dos programas em procedimentos, estruturas semi-autônomas e reutilizáveis nos programas. Os programas assim ficam subdivididos em dados e procedimentos. Essa abordagem possibilitava a criação de biblioteca de funções que possibilitava um bom nível de reuso, porém ainda não existia o conceito de herança, ou seja, não havia possibilidade de se criar procedimentos mais específicos a partir de outros mais genéricos. Além disso, não havia uma proteção sobre os dados e procedimentos dos programas. Assim um programador mal intencionado podia alterar essas informações comprometendo a qualidade dos programas.

Na tentativa de melhorar as deficiências apresentadas pela programação orientada a procedimentos, surge a programação modular cuja estrutura dividia os programas em módulos combinado os dados e os procedimentos dos programas. Essa abordagem resolvia parte do problema, porém ainda havia falhas no reuso de código e no encapsulamento dos dados.

A programação Orientada a Objetos vem como alternativa para solução desses problemas, promovendo diversos benefícios. Dentre os quais podemos citar: O reuso de código, a modularização e a simplificação de programas e ainda a redução dos custos de manutenção dos programas produzidos seguindo esse paradigma.

Como podemos concluir cada evolução na forma de se programar computadores não surge por acaso. Atualmente busca-se uma forma de se programar computadores de forma mais conceitual, ou seja, onde o programador apenas diz o que quer que o programa faça e a linguagem ou tecnologia de programação se encarrega “do como” atender ao pedido do programador. Parece-me que a OMG patrocina uma iniciativa desse tipo. Seu nome é MDA (Model-driven architecture). Eu ainda não estudei o assunto, mas quem se antecipa sai na frente.

Bom pessoal é isso aí.

Organizando as coisas e acelerando o processo.

Bom, se você seguiu algum dos caminhos citados no post anterior, mais especificamente o caminho do desenvolvimento de sistemas, já deve estar fazendo alguma coisa em relação a programação de computadores.

Você decidiu se dedicar a área de desenvolvimento de sistemas. Implementou um monte de algoritmos. Experimentou na prática uma série de técnicas de programação e com certeza chegou a uma conclusão de que apesar da evolução das linguagens de programação, programar é algo que demanda bastante tempo e esforço.

Tempo para escrever o código fonte dos programas, para testar e muito tempo para manter os sistemas que já foram desenvolvidos.

Enquanto isso acontece, seus clientes querem melhorias nos programas já desenvolvidos e novos clientes surgem com prazos apertadíssimos para o desenvolvimento de novos sistemas, com custos cada vez menores, cuja qualidade é essencial e onde há poucos recursos disponíveis.

Hoje o mercado de software demanda programas cada vez mais sofisticados, com prazos de entrega cada vez mais apertados. O cliente quer um produto de software de alta qualidade, baixo custo e tempo de entrega pequeno. Cabe aqui a seguinte pergunta: como chegar a uma equação utilizando essas grandezas inversamente proporcionais?

O primeiro passo dado nesse sentido foi o de incrementar o processo de manufatura de software. Não foi a toa que houve uma evolução nas técnicas de programação de computadores. Essa evolução surgiu da necessidade de acelerar o processo de desenvolvimento, promovendo o reuso de código, visando a facilidade de manutenção, sem que os produtos de software produzidos perdessem qualidade.

Nesse contexto, surgem a programação estruturada, a programação baseada em eventos, programação Orientada a Objetos, a programação orientada a aspectos e por aí vai.

Seguindo esta linha, surge também os designs patterns, que nada mais são do que nomes dados as técnicas conhecidas no mercado e que as empresas de software adotam para organizar os códigos-fonte que constituem os sistemas desenvolvidos por essas empresas.

As fábricas de software tiveram que adequar seus métodos de produção por conta das exigências de mercado citadas acima e para isso utilizaram as boas práticas de produção de software.

Além disso, as empresas de software criaram ou adotaram metodologias para a condução das atividades de desenvolvimento. A palavra metodologia deriva da palavra método e podemos definir método como sendo um conjunto de tarefas ou atividades que são necessárias para a conclusão de algum serviço ou objetivo.

Modelos de ciclos de vida como o modelo em cascata, espiral entre outros são criados de modo a nortear o processo de desenvolvimento de software.

Na área de desenvolvimento de sistemas existem duas metodologias que se destacam no mercado: O RUP (Rational Unified Process) e o XP (Extreme program). Logicamente, uma empresa pode desenvolver uma metodologia ou processo de desenvolvimento de software próprio, porém uma grande quantidade de empresas de software adota metodologias já experimentadas no mercado ou criam processos baseados nessas metodologias. Neste âmbito, não podemos deixar de mencionar o CMMI e o MPS BR que certificações centradas na qualidade e na melhoria de processos de desenvolvimento.

Enfim, o lema é encontrar meios de organizar o processo.