Projetar para quê?

Projetar pra quê?!

Ih cara, larga esses desenho e esses rabisco aí, ta perdendo tempo!
O tempo que você ta gastando fazendo esses diagramas já dava pra ter implementado uns 10 métodos

Nessa postagem vou relatar um pouco da experiencia que tive nesse período da faculdade cursando a matéria de Projeto de Sistemas e alguns casos de aplicações dela ou a falta dela nesse período em projetos de outra disciplina causaram.

A principio não tive grandes expectativas para essa disciplina, mas ela acabou se mostrando de uma importância que é até difícil mensurar, aprendemos  a importância e os benefícios de planejar bem antes de chegar colocando a mão na massa, como modelar "problemas" e "soluções" para facilitar o entendimento do cliente quanto a do próprio desenvolvedor. No decorrer do Semestre aprendemos vários modelos pra aplicações em etapas diversas do desenvolvimento, e olha.... não foram poucos não, pra falar a verdade só nesse ultimo mês que eu finalmente consegui assimilar alguns nomes a modelos.

Bom, eu não cheguei a ouvir as frases citadas no subtitulo do post, mas admito que já pensei nelas e acredito que muitas empresas possam pensar assim, tentado visar uma maior produtividade ou lucro, mas mal sabem o quanto prejudicial tal decisão pode ser para o seu projeto. Pra falar a verdade, agora são 04:50 de uma sexta, e advinha só?! Estou fazendo essa postagem justamente agora pois se dormir a chance de acordar é baixa, tenho prova as 7:30 e fiquei até 20mn atrás corrigindo problemas em um pequeno projeto que não existiriam se o gênio  que mesmo fazendo Projeto e sabendo da importância decidiu não utilizar oque estava aprendendo. Um projeto de desenvolvimento de um sistema que aparentemente simples, sendo feita em conjunto com mais dois amigos, graças não ter projeto praticamente nada do sistema + diretrizes de trabalho confusa e falta de comunicação com o cliente junto com somente um único diagrama de projeto acabou resultando em Muiiiiiito retrabalho, tendo que refazer todo o projeto 2x, graças a Classes estruturadas de maneira errada e soluções que não batiam com o esperado pelo cliente. As vezes as pessoas só aprendem sofrendo na pele kkkk

Então galera fica a dica, não liguem de perder algumas horas fazendo modelos, diagramas, estruturando bem as soluções. Façam o diagrama de classe, projeto, arquitetura, interface, persistência, todos que acharem necessários para o projeto que estão desenvolvendo, é melhor  perder algumas horas projetando do que dias com retrabalho, correções e muiitas outras coisas que poderiam ter sido evitadas realizando um pequeno projeto antes de ir metendo o loco.

Pra finalizar, sei que a maioria já deve conhecer essa imagem, mas ela é um clássico se tratando de projeto/desenvolvimento e eu não poderia deixar ela passar.

Read More →

Padrões GRASP

Eae pessoal, hoje iremos falar um pouco sobre GRASP, mas para inicio de conversa, o que é o GRASP? É um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidade escrito na forma de padrões.

Um padrão do GRASP é um par de um problema e uma solução

Primeiro Padrão - Information Expert: Consiste em atribuir a responsabilidade ao objeto que tem a informação necessárias para realiza-la. Com isso o encapsulamento é mantido e o comportamento é mais bem distribuído entre as classes, mas há situações onde a solução sugerida leva a problema de acoplamento e coesão.

Segundo Padrão - Creator: Com o Creator é decidido quem deve ser o responsavel por criar uma nova instancia de uma classe da seguinte maneira, A Classe X deve criar uma Classe Y se:
X agrega objetos da classe Y
X contém objetos de Y,
X armazena  instancias de Y
X, de forma privada, usa instancia de Y
X tem dados necessários para inicializar Y
Com o Creator é possível manter estável o grau de acoplamento entre as classes, mas quando a criação de uma instancia for muito complexa, envolvendo dependências tecnológicas ou subsistemas externos, é preferível delegar essa responsabilidade a um Factory

Terceiro Padrão - Baixo Acoplamento: Reduz o impacto das mudanças atribuindo a responsabilidade de forma a manter o acoplamento baixo, isso potencializa o reuso, facilita o entendimento e minimiza os efeitos de mudanças, mas  o principio utilizado ao extremo leva a um  design pobre.

Quarto Padrão - Alta Coesão: Visa manter os objetos focados, fáceis de entender, gerenciar e ainda pouco acoplados e isso é feito atribuindo a responsabilidade de forma a manter a coesão funcional alta, com isso, aumenta a clareza do projeto, aumenta potencial de reuso e geralmente promove menor acoplamento.

Quinto Padrão - Controlador: Os eventos de sistemas devem ser atribuídos a uma classe que represente todo o sistema ou um subsistema, é a classe raiz do sistema/modulo. Trás benefícios como aumento de potencial de reuso, permite a criação de interfaces plugáveis e define claramente pontos de entrada no sistema, mas na hora de utilizar esse padrão a falta de analise de coesão, pode levar a criação de  controladores inchados, cheios de métodos pouco relacionados entre si.

É necessário as vezes usar mais de um padrão em um mesmo "pedaço" de projeto pois é necessário escolher entre os usados o que apresentar um resultado melhor. É bom lembrar também que o padrão GRASP não é algo fixo que sempre deve ser utilizado em qualquer caso, ele é só mais um conjunto de padrões no mercado dentre tantos outros que podem ser utilizados em um projeto, como o SOLID e GoF. Caso tenham interesse em mais informações sobre o GRASP, só clicar AQUI para ter acesso a um conjunto de video-aulas sobre o tema abordado

Read More →

Padrões GoF

Fala pessoal, hoje iremos falar dos Padrões GoF, mas o que é GoF?

Primeiro, deixa eu dizer o que significa GoF, GoF é uma sigla para "Gang of Four" ou em PT-BR, Gangue dos Quatro, esse nome surgir porque em 1994 quatro autores, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, publicaram o livro o Design Patterns: Elements of Reusable Object-Oriented Software que mostrava conceitos de padrões de projeto para o desenvolvimento de software. Graças ao livro e aos quatro autores que os padrões citados ficaram conhecidos com esse nome.

Os Padrões GoF são 23 padrões que são divididos em 3 grupos cada um dos grupos visa solucionar um tipo de cenário com um determinado problema.

Grupo 1  - Padrões de Projeto de Criação

Estes padrões lidam com o processo de criação de novos objetos de uma forma que ele pode ser desacoplado do seu sistema de implementação. Isso fornece mais flexibilidade em decidir quais objetos precisam ser criados para um determinado  caso ou cenário.

• Factory Method : Cria instâncias de classes derivadas
• Abstract Factory : Cria instâncias de muitas classes  several classes pertencentes a diferentes famílias
• Builder : Separa a construção do objeto de sua representação
• Prototype : Cria um objeto duplicado ou um clone do objeto
• Singleton : Garante que a classe só tenha uma instância

Grupo 2  - Padrões de Projeto Estruturais

Estes padrões lidam com a composição das estruturas dos objetos. O conceito de herança é usado para compor interfaces e definir várias formas de compor objetos para obter novas funcionalidades. 

• Adapter : Combinar interfaces de classes diferentes
• Bridge : Separar uma abstração de objeto de sua implementação
• Composite : Uma estrutura em árvore de simples e objetos compostos
• Decorator : Adicionar responsabilidades para objetos dinamicamente
• Façade : Uma simples classe que representa um complexo sistema inteiro
• Flyweight : Minimizar o uso da memória compartilhando o máximo de dados possível com objetos similares
• Proxy: Fornece um objeto substituto, que faz referência a outro objeto

Grupo 3  - Padrões de Projeto Comportamentais

Estes padrões lidam com o processo de comunicação, gerenciamento de relações, e responsabilidades entre objetos.

• Chain of Responsibility: Passa uma requisição entre uma lista ou objetos encadeados.
• Command: Embrulha uma requisição em um objeto como um comando e passa para o objeto invocador
• Interpreter: Implementar uma linguagem computacional especializada para resolver problemas específicos rapidamente
• Iterator: Iterators são usados para acessar os elementos de um objeto agregado sequencialmente sem expor sua
• Mediator: Fornece uma interface unificada para um conjunto de interfaces em um subsistema
• Memento: Oferece a capacidade de restaurar um objeto ao seu estado anterior(rollback)
• Observer: Objetos registrados para observar um evento que pode ser disparado por outro objeto.
• State: Uma maneira limpa para um objeto mudar parcalmente seu tipo em tempo de execução
• Strategy: Algoritimos podem ser selecionados em tempo real
• Visitor: Um modo e separar um algoritmo de um objeto
• Template Method: Descreve o esqueleto de um programa

Bom, esse post foi só pra dar uma explicação simples e básica do que é, de onde surgiu e como funciona um pouco desses padrão de projeto, para auxiliar no momento de escolha de um conjunto de padrões para aplicar em seu projeto, tendo uma gama maior de opções.

Fonte1
Fonte2

Read More →

Modelos Anêmicos & Modelos Ricos

O que são modelos anêmicos? são modelos que não comem feijão?! NÃO!São modelos muito magros?! Tão pouco!

#Referencia

Segundo o Alexandre Valente no podcast que irei postar no final desse post os modelos anêmicos são aqueles que as regras de negocio estão isoladas da entidade de domínio, os modelos anêmicos utilizam mais uma estrutural procedural em vez de conceito de objetos, ele é focado nos dados e cada dado não tem seus métodos como um objeto, já o método tende a ter uma visão mais parecida com o mundo real, utiliza o conceito de objeto e dados e métodos estão na mesma classe .

Sabendo o que é cada um, vamos falar um pouco de suas diferenças no momento de implementar cada um. Depois de muita discussão no podcast eles entram meio que em um "consenso"(nem todos) que a unica diferença entre os dois é a produtividade, que é o que eu concordo particularmente.


No decorrer do podcast é citado varias vezes onde o modelo anêmico foi mais fácil de implementar e mais produtivo, mas porque isso acontece?! Isso acontece pois os desenvolvedores precisa de pouco entendimento como o negocio funciona por completo, diminuindo o tempo em que os desenvolvedores gastariam para entender o negocio, além dos programadores em sua grande maioria terem mais facilidade de entender/desenvolver de maneira procedural. O modelo rico depende muito de um bom entendimento do negocio.

Com isso podemos concluir que o mais utilizado atualmente no mercado são os modelos anêmicos por sua simplicidade e facilidade de implementação, visto que no modelo rico é preciso ter um bom conhecimento do negócio e entender bem POO, coisa que se gasta tempo e muitas vezes no mercado não se tem esse tempo, mas isso não quer dizer que um seja melhor que o outro, a implementação de cada um vai pelo nível da equipe, tamanho do projeto e o tempo disponível para o desenvolvimento do mesmo.

Read More →

Arquitetura de Software

Fala Pessoal, hoje iremos falar um pouquinho sobre o que é Arquitetura de Software?!

A arquitetura de software de um sistema consiste na definição dos componentes do software, da sua estrutura, consistindo de elementos de software, propriedades externamente visíveis desses elementos e os relacionamentos entre eles. A arquitetura define elementos de software (ou módulos) e envolve informações sobre como eles se relacionam uns com os outros. A arquitetura omite certas informações sobre os elementos que não pertencem às suas interações. Assim, uma arquitetura é antes de tudo uma abstração de um sistema que suprime detalhes dos elementos que não afetam como eles são usados. Na maioria das vezes essa descrição abstrata é relatada em forma de modelos.

Iremos citar alguns principais estilos e padrões arquiteturais para Sistemas de Informação.

Um estilo arquitetônico define um vocabulário de tipos de elementos e tipos de relacionamentos, e um conjunto de restrições sobre como eles podem ser combinados. Padrões arquitetônicos também estabelecem tipos de elementos e de relacionamentos entre eles, mas sua apresentação segue uma forma bem definida, indicando nome, contexto, problema, solução e consequências. Assim, normalmente, estilos têm uma apresentação mais livre e são descritos de maneira mais abstrata que padrões arquitetônicos.

Cinco categorias principais de estilos arquitetônicos, contendo algum grau de sobreposição entre elas:

• Sistemas de Fluxo de Dados: são caracterizados pelo modo como dados se movem através do sistema.

• Sistemas de Chamada e Retorno: são caracterizados por um modelo de ativação que envolve a linha principal de controle que realiza invocações explícitas de operações.

• Componentes Independentes: este estilo fia-se na invocação implícita de operações, ou seja, a invocação de uma operação é desacoplada de sua execução, de modo que os componentes chamador e chamado podem existir em processos separados e possivelmente distribuídos em processadores distintos.

• Máquinas Virtuais: uma máquina virtual é desenvolvida em software, contendo uma máquina de interpretação, uma memória contendo o código a ser interpretado, uma representação do estado da máquina de interpretação e uma representação do estado corrente do programa.

• Repositórios: esta categoria envolve um repositório de dados compartilhado para a passagem de informações.

Para encerrar irei falar de maneira breve o que é SOA.

SOA ou Arquitetura Orientada A Serviços, corresponde a uma metodologia para desenvolvimento de software, focado em disponibilizar e consumir serviços principalmente online para que o um mesmo serviço seja reaproveitado gerando uma gama de benefícios como: Reutilização, Facilidade de manutenção, Flexibilidade entre outros.

Contudo podemos observar que uma Arquitetura bem elaborada para um software trás diversos benefícios no momento de criação do mesmo e até mesmo após a criação seja facilitando o reuso de serviços, economizando recursos, evitar erros e até tornar a manutenção futura mais fácil.

Read More →

Qualidade de Software

O que é qualidade de software?
Qual a sua importância?
Como especificar?
Como descobrir atributos de qualidade?

Hoje no Coco Xarope

Antes de mais nada, gostaria de informar que boa parte do conteúdo da postagem de hoje é baseada nesse ---> podcast <----  Irei abordar o tema de maneira que mesmo que você que não tenha ouvido o podcast e nem quer ouvir possa entender sem ficar boiando, mas pra uma visão ainda maior do assunto recomendo que ouçam.

Afinal o que é ter qualidade? Se te perguntassem o que tem mais qualidade um Fusca ou uma Ferrari o que você responderia? (Inclusive essa foi uma das analogias usadas no podcast pelo Geovani)



Agora pensando de novo, levando em conta o publico alvo, o custo de produção, valor final, qual tem mais qualidade? Eu diria que é aquele que atendeu suas especificações de construção após ser feito, a final, se eu projetei o Fusca pra atingir 80km e ele atinge os 80km ele tem mais qualidade que uma ferrari que foi projetada para atingir 250km e atinge apenas 150km, mesmo sendo superior ao fusca.

No podcast foram abordados algumas opiniões sobre o assunto, alguma das citadas e que bate com o que eu penso sobre o assunto é que qualidade é cumprir as especificações/prazos, é cumprir com as métricas estabelecidas pela equipe e pelo cliente, além de ajudar o próprio cliente a defini-las, trazendo a satisfação para o mesmo.

A importância da qualidade de software se dá a N fatores, afinal se o software não está atendendo aos requisitos do cliente tem grande chaces dele desistir da sua equipe. A falta de qualidade também acaba gerando gastos quando não atendidos, para o cliente cliente devido a manutenção, necessidade de troca, treinamento para equipe. Prejuízos para as empresas que prestam manutenção, prejuízo de sujar a imagem da própria equipe que desenvolveu.

- Poh Carlos, mas se eu contrato uma equipe pra desenvolver e eu vejo que não estão atendendo o que eu pedi eu já mando embora, não vou receber um projeto que não me atende!

É meu amigo, concordo com você, mas e quando o próprio cliente não sabe o que quer? Talvez o cliente ache que usar Framework X-23 Novo Lançamento que pisca seja o melhor, mas cabe também aos desenvolvedores orientar o cliente que o ideal pra situação que ele passa seja o Framework Z-Normalzim. 

- Ok Ok, mas como faço para definir essas métricas/especificações? Como posso ser orientado do que seria melhor? e como descobrir atributos de qualidade?

Como citado no podcast várias vezes, pode ser usado Metodologias Ágeis, mantendo o cliente perto, o orientar do que é qualidade, das ferramentas que melhor iram atende-lo, estabelecer juntos métricas, especificações e técnicas de medição de qualidade, para que o software possa ter qualidade, manter o cliente sempre próximo do desenvolvimento e do andamento do projeto.

Em alguns casos é melhor não aceitar o projeto visto que as métricas/especificações do cliente vão ser prejudiciais para equipe de desenvolvimento e até para o cliente, e o mesmo não aceita realizar alterações. Um bom desenvolvedor defini métricas próprias de qualidade como Número máximo de bugs, taxa de reutilização de código, entre outros;  procurar sempre no que melhorar em cada projeto é algo que não pode faltar, afinal isso vai te ajudar a sempre se manter atualizado no mercado e te fortalecer contra a concorrência.

Read More →

Arquiteto de Software

O que é um Arquiteto de Software?
Onde vivem?
O que comem?
Eles estão surgindo ou sendo extintos?
Hoje no Globo Reporter

Bom, antes de começarmos a discutir se um Arquiteto de Software é uma profissão ou um papel, se está em ascendência ou decadência, quantos dinheiros ganha, precisamos primeiro saber o que é SER um Arquiteto de Software, quais suas funções.

Vamos lá, um Arquiteto de Software é algo fundamental para o desenvolvimento de software.

- Nossa Carlos, como assim é fundamental? Na minha equipe não tem nenhum Arquiteto de Software!

Muitas vezes a equipe pode não ter um Arquiteto de Software ou uma pessoa especifica com esse papel, mas sem duvidas ele está presente, ele é aquela pessoa que "segura o rojão", aquele que orienta e direciona o projeto, o responsavel por decidir as ferramentas e tecnologias usadas. Algumas empresas escolhem ter esses profissionais, exclusivamente para essas tarefas e outras escolhem de dar esse "papel" para algum funcionário exercesse, as vezes até alterando tal funcionário. Acredito que com o passar do tempo esses profissionais sejam cada vez mais reconhecidos e deixem de ser um papel que alguém dentro da empresa possa assumir, visto que cada vez mais os profissionais de TI está buscando se especializar em uma área e o Arquiteto precisa de uma visão mais ampla, além de ter que estar sempre estudando e conhecendo novas tecnologias. Embora a cobrança em cima dos Arquitetos de Softwares para se aperfeiçoarem, estudarem e descobrirem novas tecnologias seja maior do que a grande maioria dos outros profissionais de TI ela é bem compensada com uma média salarial de  R$ 10.643,00.

Portanto mesmo que algumas empresas não valorizem tanto o Arquiteto de Software ele é cada vez mais necessário. Caso você tenha interesse em saber um pouco mais sobre Arquiteto de Software é só conferir esse podcast.

Read More →