O primeiro tópico deste blog foi dedicado a uma linguagem iconográfica de desenvolvimento de software, porque de facto as "boas praticas" sempre estiveram no meu âmbito de preocupação e daqueles que geriam os projectos (ainda poucos) nos quais trabalhei, a eles um obrigado pelas palavras motivadoras em tempos de crise e as congratulações nos momentos altos. Não é fácil saber qual a metodologia a aplicar num determinado projecto, porque as metodologias estão intimamente ligadas às pessoas que as põem em prática, e aí está como sabemos o grande desafio.
Independentemente disso existe a teoria, muito sucintamente enumero algumas.
Model Driven Development – MDD
Metodologia baseada na criação de modelos conceptuais que servem de base para a criação de artefactos de software.
RUP
Rational unified process é uma metodologia orientada a objectos com grande ênfase na linguagem UML, processos de planificação e controle têm grande destaque, começando logo num levantamento exaustivo dos requisitos e planificação e documentação de todos os detalhes até uma verificação exaustiva da qualidade do software e sua adaptação e mudança.
AS METODOLOGIAS AGILE
Metodologia de desenvolvimento de software com carácter iterativo, com planificações informais para curtos períodos de tempo, e focados na inter-ajuda e partilha de conhecimentos para atingir os objectos. Ao longo do ciclo de vida do projecto os objectivos são reprogramados e reavaliados tendo como objectivo maior a satisfação do cliente e entrega de aplicações funcionais, por norma faseadas em várias versões.
XP - extreme programming
Metodologia ágil de desenvolvimento de software, receita: simplicidade, mudandança, feedback, coragem; Por outras palavras encontrar as melhores soluções em equipa, em constante comunicação com feedback rápido e aberto à mudança, numa atitude de crescente melhoria e procura de qualidade e responsabilidade.
Agile Model Driven Development (AMDD)
É a versão agile de desenvolvimento orientado a objectos, na qual se investe um tempo para uma modelagem inicial. basicamente é uma analise mais atenta ao requisitos funcionais de modo a projectar e a potencializar as construção de uma boa arquitectura.
css
CSS, cascating style sheets é uma linguagem de estilo com enormes potencialidades e usado em grande escala para formatar documentos escritos em linguagens de tags, como por exemplo html ou xml. Ou seja uma ferramenta essencial para quem quer criar sites de qualidade; preocupados com as regras de usabilidade e standards, com vista a uma maior simplicidade e consequente melhor performance.
O que mais chateia os desenvolvedores de hoje é a diferença de interpretação ao nível dos browsers, que apesar de todas as normas e organizações criadas as diferenças continuam a ser preocupantes e aborrecedoras. Claro que os browsers devem ter diferenças entre si, a sua "vantagem competitiva"... mas isto não é desculpa, pois podem disponibilizar métodos próprios e garantias de segurança melhores e cumprir na mesma as normas estabelecidas... não me parece de todo impossível...
O maior problema no desenvolvimento de css nos projectos web é a falta de planeamento; de facto, é necessário um trabalho inicial de abstracção de modo a evitar a redundância e ficheiros intermináveis. Outro problema tem haver com, "cada um faz à sua maneira" e "toda a gente vai lá mexer". É necessário criar módulos reutilizáveis e folhas leves e simples; separar estrutura de estilo e o contentor do conteúdo.
Na verdade, encontramos nas css, muitos aspectos recorrentes nas linguagens orientadas a objectos, o segredo é olhar para os problemas e encontrar as diversas entidades, os objectos. Assim que conseguirmos definir estes elementos na nossa interface poderemos estruturar melhor os elementos e criar folhas de estilo eficientes.
O que mais chateia os desenvolvedores de hoje é a diferença de interpretação ao nível dos browsers, que apesar de todas as normas e organizações criadas as diferenças continuam a ser preocupantes e aborrecedoras. Claro que os browsers devem ter diferenças entre si, a sua "vantagem competitiva"... mas isto não é desculpa, pois podem disponibilizar métodos próprios e garantias de segurança melhores e cumprir na mesma as normas estabelecidas... não me parece de todo impossível...
O maior problema no desenvolvimento de css nos projectos web é a falta de planeamento; de facto, é necessário um trabalho inicial de abstracção de modo a evitar a redundância e ficheiros intermináveis. Outro problema tem haver com, "cada um faz à sua maneira" e "toda a gente vai lá mexer". É necessário criar módulos reutilizáveis e folhas leves e simples; separar estrutura de estilo e o contentor do conteúdo.
Na verdade, encontramos nas css, muitos aspectos recorrentes nas linguagens orientadas a objectos, o segredo é olhar para os problemas e encontrar as diversas entidades, os objectos. Assim que conseguirmos definir estes elementos na nossa interface poderemos estruturar melhor os elementos e criar folhas de estilo eficientes.
começar bem
Conceber, implementar, instalar e manter. Os projectos têm um ciclo de vida, é necessário respeitar o seu ritmo e tirar partido de cada uma das fases. Claro que não existem receitas mágicas. Por um lado não podemos cair em psicoses documentativas e planificações elaboradas, por outro, ter o projecto apenas na "cabeça da pessoas" é um risco elevado com tendência para o caos.
Primeiramente é necessário fazer o levantamento de requisitos: o que a aplicação tem que fazer; como ela vai fazer; e a melhor forma de o fazer. Existem diversos programas e aplicações que auxiliam em todas estas tarefas, tornando simples e rápido manter um registo e controle sobre cada uma das fases. É necessário preparar a equipa, envolve-la de modo a que todos os membros tenham uma visão global do sistema e pormenorizada das suas funções, motivadas em encontrar as melhores soluções.
Para auxiliar o entendimento e ter uma visualização aproximada da realizade do problema existem os diagramas de Use cases, "casos de utilização", no qual representamos uma sequência de eventos com resultados relevantes no ponto de vista de uma acto (aquele/aquilo que executa uma determinada acção ou interage com o sistema). Os uses cases são mais centrados no que o sistema deve fazer do que como ele vai fazer. Eles devem ser detalhados e neles podemos representar os vários cenários possíveis e as relações entre acções.
Um dos tipo de diagrama usados em maior escala no UML são os diagramas de classes, uma vez que o UMl é muito optimizado para representações baseadas no paradigma orientado a objectos. Um objecto representa uma determinada entidade, a sua identificação resulta de um processo de abstracção no qual descrevemos as suas atributos e comportamentos. Uma Classe é uma abstracção sobre um conjunto de objectos que partilham a mesma estrutura e comportamento.
Para a modelagem de comportamentos temos dois diagramas os de interação, centrados nos comportamentos inter-objectos, e os diagramas de estado e actividades na modelagem do comportamento intra-objecto.
Os diagramas de interacção subdividem-se em diagramas de colaboração e sequência; pretendem representar a dinâmica de um sistema, definir e clarificar a colaboração e troca de mensagens entre as classes do sistema. Os diagramas de sequência têm a pecularidade de representarem a informação temporalmente.
Os diagramas de estados descrevem comportamentos de um objecto. Estado é um momento ou situação relativamente estável durante um determinado periodo de tempo; a transição de estado surge da acção de estimulos sobre o objecto. Os diagramas de estados estão centrados nos objectos, os de actividades nos processos. estes ultimos, os diagramas de actividades exigem a identificação das responsabilidades do projectos na realização de cada uma das actividades do sistema.
Primeiramente é necessário fazer o levantamento de requisitos: o que a aplicação tem que fazer; como ela vai fazer; e a melhor forma de o fazer. Existem diversos programas e aplicações que auxiliam em todas estas tarefas, tornando simples e rápido manter um registo e controle sobre cada uma das fases. É necessário preparar a equipa, envolve-la de modo a que todos os membros tenham uma visão global do sistema e pormenorizada das suas funções, motivadas em encontrar as melhores soluções.
Para auxiliar o entendimento e ter uma visualização aproximada da realizade do problema existem os diagramas de Use cases, "casos de utilização", no qual representamos uma sequência de eventos com resultados relevantes no ponto de vista de uma acto (aquele/aquilo que executa uma determinada acção ou interage com o sistema). Os uses cases são mais centrados no que o sistema deve fazer do que como ele vai fazer. Eles devem ser detalhados e neles podemos representar os vários cenários possíveis e as relações entre acções.
Um dos tipo de diagrama usados em maior escala no UML são os diagramas de classes, uma vez que o UMl é muito optimizado para representações baseadas no paradigma orientado a objectos. Um objecto representa uma determinada entidade, a sua identificação resulta de um processo de abstracção no qual descrevemos as suas atributos e comportamentos. Uma Classe é uma abstracção sobre um conjunto de objectos que partilham a mesma estrutura e comportamento.
Para a modelagem de comportamentos temos dois diagramas os de interação, centrados nos comportamentos inter-objectos, e os diagramas de estado e actividades na modelagem do comportamento intra-objecto.
Os diagramas de interacção subdividem-se em diagramas de colaboração e sequência; pretendem representar a dinâmica de um sistema, definir e clarificar a colaboração e troca de mensagens entre as classes do sistema. Os diagramas de sequência têm a pecularidade de representarem a informação temporalmente.
Os diagramas de estados descrevem comportamentos de um objecto. Estado é um momento ou situação relativamente estável durante um determinado periodo de tempo; a transição de estado surge da acção de estimulos sobre o objecto. Os diagramas de estados estão centrados nos objectos, os de actividades nos processos. estes ultimos, os diagramas de actividades exigem a identificação das responsabilidades do projectos na realização de cada uma das actividades do sistema.
UML
UML (unifed modeling language) é uma linguagem de cariz gráfico cujo valor reside na comunicação e entendimento na execução de um projecto. Sendo, por norma, as equipas multidisciplinares é necessário uma planificação que seja entendida por todos de modo a minimizar os erros invitáveis da comunicação provenientes, a maior parte, de estereótipos, preconceitos e mau feitio comuns em todas as pessoas.
É em 1997 que surge o uml unificando diversos tipos de notações gráficas, claro que por si só não resolve todos os problemas num processo de engenharia de software ou mecanismos, todavia, se bem usada poderá facilitar em muito a execução de um projecto. O UML está intimamente ligado à modelagem orientada a objectos e a disputas metodológicas de padronização.
Mais do que encontrar bons diagramas explicativos do problema o uml pretende encontrar metamodelos, ou seja, descrições dos conceitos de um domínio de estudo.
Abordagens mais recentes encaram o UML como uma linguagem de programação, é uma possibilidade real e com imensa potencialidade; contudo, nos dias de hoje define uma notação e um metamodelo. Notação pois tem uma sintaxe gráfica de modelagem própria e metamodelo pois demonstra características, relacionamentos, interacções e estados.
Sendo assim, encontramos para um mesmo problema a possibilidade de o explicar, exemplificar e simplificar de diversas perspectivas, com detalhes distintos e focando aspectos diferentes. O vários tipos de diagramas permitem esta flexibilidade.
Podemos dividir os diagramas em dois grandes grupos, os diagramas de estrutura e os de comportamento. Os diagramas de estrutura englobam os diagramas de classes, objectos, componentes, pacotes, instalação e estruturas compostas. Nos de comportamento encontramos os diagramas de actividades, use cases, estados e interacções, estes últimos poderão subdividir-se em diagramas de sequência, comunicação, interacção geral e sincronização.
Referências ao livro UML Essencial - Fowler, Martin
É em 1997 que surge o uml unificando diversos tipos de notações gráficas, claro que por si só não resolve todos os problemas num processo de engenharia de software ou mecanismos, todavia, se bem usada poderá facilitar em muito a execução de um projecto. O UML está intimamente ligado à modelagem orientada a objectos e a disputas metodológicas de padronização.
Mais do que encontrar bons diagramas explicativos do problema o uml pretende encontrar metamodelos, ou seja, descrições dos conceitos de um domínio de estudo.
Abordagens mais recentes encaram o UML como uma linguagem de programação, é uma possibilidade real e com imensa potencialidade; contudo, nos dias de hoje define uma notação e um metamodelo. Notação pois tem uma sintaxe gráfica de modelagem própria e metamodelo pois demonstra características, relacionamentos, interacções e estados.
Sendo assim, encontramos para um mesmo problema a possibilidade de o explicar, exemplificar e simplificar de diversas perspectivas, com detalhes distintos e focando aspectos diferentes. O vários tipos de diagramas permitem esta flexibilidade.
Podemos dividir os diagramas em dois grandes grupos, os diagramas de estrutura e os de comportamento. Os diagramas de estrutura englobam os diagramas de classes, objectos, componentes, pacotes, instalação e estruturas compostas. Nos de comportamento encontramos os diagramas de actividades, use cases, estados e interacções, estes últimos poderão subdividir-se em diagramas de sequência, comunicação, interacção geral e sincronização.
Referências ao livro UML Essencial - Fowler, Martin
Subscrever:
Mensagens (Atom)
