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.
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)
