DEV Community: Pedro

Engenharia de Software #02 - SOLID 101

Pedro — Sun, 13 Aug 2023 19:13:35 +0000

Durante a vida útil de um software, a maior parte do custo do desenvolvimento de software é gasto na manutenção do software. Então, como desenvolvedores, queremos construir algo que não seja frágil, mas fácil de manter. E utilizar algumas regrinhas do SOLID pode nos ajudar a chegar nesse nível

Single Responsability Principle

public class SonoplastaRodrigoFaro {

    // Audio é um texto em representação aos bordões
    private List<String> audios = new ArrayList<>();
    private Integer count = 0;

    public void addAudio(String audio) {
        StringBuilder stringBuilder = new StringBuilder();

        String stringNova = stringBuilder
                .append(++count)
                .append(":")
                .append(audio)
                .toString();

        audios.add(stringNova);
    }

    public void removeAudio(String audio) {
        audios.removeIf(a -> a.equals(audio));
    }

    public List<String> getAudios() {
        return audios;
    }

    public Optional<String> getAudio(String audio) {
        return audios.stream()
                .filter(a -> a.equals(audio))
                .findFirst();
    }
}
}

Temos aqui a classe Sonoplasta, que tem como atributos um contador de entradas e uma Lista de audios, e métodos fazem os CRUD desses respectivos áudios.

É uma classe com responsabilidades de Sonoplastia apenas, não há persistência e nem outras responsábilidades.

Código da persistência:

public class SonoplastaPersistence {

    public final static String PATH = "/home/pedro/Documentos/audios.txt";

    public void persist(List<String> audios) throws IOException {

        try(BufferedWriter bufferedWriter = new BufferedWriter(new FileWriter(PATH))) {

           String entradas = audios
                   .stream()
                   .map(item -> String.valueOf(item))
                   .collect(Collectors.joining("|"));

           bufferedWriter.write(entradas);

            System.out.println("Persistido com sucesso!");

        } catch (IOException e) {
            throw new IOException("Error on persist the archive");
        }
    }
}

Classe de Persistência que gera um arquivo em um diretório de sua preferencia com as anotações do seu Journal.

public class SRP {
    public static void main(String[] args) throws IOException {
        SonoplastaRodrigoFaro sonoplasta = new SonoplastaRodrigoFaro();

        sonoplasta.addAudio("CAVALOO");
        sonoplasta.addAudio("UUUIII");
        sonoplasta.addAudio("ELE GOXXTA");
        sonoplasta.addAudio("Que isso meu fio calma");

        sonoplasta.getAudios()
                .forEach(System.out::println);

        sonoplasta.getAudio("1:CAVALOO")
                .ifPresentOrElse(audio -> System.out.println("Audio: " + audio), () -> System.out.println("Audio não existe"));


        SonoplastaPersistence sonoplastaPersistence = new SonoplastaPersistence();

        sonoplastaPersistence.persist(sonoplasta.getAudios());
    }
}

E por fim, outra classe que faz a chamada dessas duas classes.

Demonstração do funcionamento:

Arquivo persistido:

Open Closed Principle

Esse é um princípio que é bem discutido. Ele diz que uma classe DEVE estar fechada para IMPLEMENTAÇÃO porém ABERTA para EXTENSÃO. Isso quer dizer: Uma classe quando feita, não deve ser modificada e sim herdada, isso gera um certo desconforto, porque não podemos alterar nossas classes? O jeito para seguirmos bem esse principio é utilizando de Abstrações, sendo classes abstratas ou até mesmo interface. Mostrarei duas formas de utilizar esse principio.

Provavelmente, você ja criou uma calculadora na vida, e nessa calculadora devia ser algo tipo:

if (action == "+") {
  doSum();
} else if (action == "-") {
  doSubtraction();
}

e daí vai. Isso fere o OCP, porque? se criarmos a classe de calculo com esses dois métodos, teriamos mais dois para implementar depois, que seriam a divisão e multiplicação, estariamos alterando nossa classe ja pronta. Como podemos resolver isso?

Primeiro, vamos criar uma interface chamada ICalculation:

public interface ICalculation {
     void perform();
}

ela possui um método chamado perform que atuará para todas as operações básicas.

Agora criaremos uma classe para cada operação básica, implementando a interface.


public class Multiplication implements ICalculation{

    private double left;
    private double right;
    private double result;

    @Override
    public void perform() {
        result = left * right;
        System.out.println("Result of multiplication: " + result);
    }

    public Multiplication(double left, double right) {
        this.left = left;
        this.right = right;
        this.result = 0.0;
    }

    public double getLeft() {
        return left;
    }

    public void setLeft(double left) {
        this.left = left;
    }

    public double getRight() {
        return right;
    }

    public void setRight(double right) {
        this.right = right;
    }


}

faça isso para cada operação básica, apenas alterando o perform(). Percebemos que ao fazer isso, nosso código está genérico e funcionará com base nas implementações de cada operação. Exemplo:

public class OCP {
    public static void main(String[] args) {
        ICalculation calculation = new Multiplication(2, 2);
        calculation.perform();
    }
}

Podemos ver que não precisamos fazer várias estruturas de decisões para cada uma operação, basta passarmos uma instancia da implementação que queremos. Um exemplo disso acima está sendo passada a multiplicação entre dois números, se quisessemos uma soma, passariamos uma instancia de Soma e assim por diante.

Lembre-se, não leve esse principio ao pé da letra.

Specification Pattern funciona muito bem com OCP

Vamos utilizar outro exemplo pondo em prática OCP com um padrão chamado Specification.

obs: instalei o lombok, pois como faremos tudo na mesma classe devido ao tamanho do exemplo, para não ficar trocentas linhas na página estaremos utilizando as anotações do lombok para getters, setters e constructors.

public class FilterBySpecification {
    public static void main(String[] args) {
        var iphone = new Product(6.7, "iphone", 1800);
        var motorola = new Product(6.8, "motorola", 900);
        var iphoneX = new Product(6.9, "iphone", 3800);

        var listProducts = List.of(iphone, motorola, iphoneX);

        FilterProduct filterProduct = new FilterProduct();

        filterProduct.filterByName(listProducts, "iphone")
                .forEach(System.out::println);

    }

    static class FilterProduct {
        public List<Product> filterByName(List<Product> products, String name) {
            return products.stream()
                    .filter(product -> product.getName().equals(name))
                    .collect(Collectors.toList());
        }
    }

    @Data
    @AllArgsConstructor
    @ToString
    static class Product {
        public double size;
        public String name;
        public double price;

    }
}

Logo acima, temos 3 classes simples, uma de produtos, uma para o método maine outra para a filtragem de produtos. podemos ver que ja filtramos produtos pelo nome, isso está certo, porém, se o seu chefe te pedir para filtrar por PREÇO também? depois por Tamanho? depois por Preço e Tamanho, e assim por diante? você adicionaria mais métodos dentro da classe ja pronta? um filterBySize? Bom, funcionaria porém fere o Open Closed Principle, desta forma, podemos implementar usando um padrão chamado Specification:

public class FilterBySpecification {
    interface Specification<T> {
        boolean isSatisfied(T item);
    }

    public static void main(String[] args) {
        var iphone = new Product(6.7, "iphone", 1800);
        var motorola = new Product(6.8, "motorola", 900);
        var iphoneX = new Product(6.9, "iphone", 3800);

        var listProducts = List.of(iphone, motorola, iphoneX);

        FilterItens filterProduct = new FilterItens();

        filterProduct.filterItem(listProducts, new NameSpecification("iphone"))
                .forEach(System.out::println);

    }

    interface Filter<T> {
        Stream<T> filterItem(List<T> itens, Specification<T> specification);
    }

    static class FilterItens implements Filter<Product> {

        @Override
        public Stream<Product> filterItem(List<Product> itens, Specification<Product> specification) {
            return itens.stream()
                    .filter(specification::isSatisfied);
        }
    }

    @AllArgsConstructor
    static class NameSpecification implements Specification<Product> {
        private String name;

        @Override
        public boolean isSatisfied(Product item) {
            return item.getName().equals(name);
        }
    }


    @Data
    @AllArgsConstructor
    @ToString
    static class Product {
        public double size;
        public String name;
        public double price;

    }
}

O que fazemos aqui: Nós criamos uma interface genérica com o nome de Specification que possui um método chamado isSatisfied() que retorna um boolean, nós implementaremos esse método em nossos specifications que são, Size, Price e Name. Esse método servirá para filtrarmos nossos itens para cada specification. E criamos também uma classe chamada FilterItens que recebe uma lista de produtos e um Specification, podendo ser size, price, name, nós podemos fazer todos esses filtros usando somente UM método, respeitando o open closed principle. Se surgir uma nova necessidade de filtro, basta apenas criar uma nova Specification, como por exemplo: SizeSpecification e fazer o filtro por SizeSpecification ao invés de NameSpecification. isso fará com que não mexemos na nossa classe que tem a regra de negócio, de filtro, respeitando o principio. Exemplo do código em funcionamento:

Bi ou mais Specifications: Também é possível fazer com que seja comparados UMA ou MAIS Specifications por filtro, por exemplo, quero filtrar um produto por PREÇO e por NOME ao mesmo tempo. Exemplo:

Em nosso código, será adicionado mais uma interface e uma classe:

    interface BiFilter<T> {
        Stream<T> filterItens(List<T> itens, Specification<T> specification1, Specification<T> specification2);
    }

    static class BiFilterItens implements BiFilter<Product> {
        @Override
        public Stream<Product> filterItens(List<Product> itens, Specification<Product> specification1, Specification<Product> specification2) {
            return itens.stream()
                    .filter(item -> specification1.isSatisfied(item) && specification2.isSatisfied(item));
        }
    }

Ele fará com que seja verificado as duas Specifications no mesmo filtro. Implemente isso no método main da seguinte forma:

    public static void main(String[] args) {
        var iphone = new Product(6.7, "iphone", 1800);
        var motorola = new Product(6.8, "motorola", 900);
        var iphoneX = new Product(6.9, "iphone", 3800);

        var listProducts = List.of(iphone, motorola, iphoneX);

        BiFilterItens filterProduct = new BiFilterItens();

        filterProduct.filterItens(listProducts, new NameSpecification("iphone"), new SizeSpecification(6.9))
                .forEach(System.out::println);

    }

Perceba que criamos uma nova Specification chamada Size, onde será feito a lógica para o tamanho

    @AllArgsConstructor
    static class SizeSpecification implements Specification<Product> {
        private double size;

        @Override
        public boolean isSatisfied(Product item) {
            return item.getSize() == size;
        }
    }

E estamos passando esse SizeSpecification como segundo parametro para o nosso filterItens.

Resultado do código:

Liskov Substitution principle

O princípio da Substituição de Liskov determina que uma classe derivada deve ser substituível por sua classe base.

Na prática, todas as classes filhas (que foram implementadas através de uma herança) devem manter os mesmos comportamentos da classe pai (Classe sendo herdada).

Vamos supor que temos uma classe Pessoa, com CPF, RG, Nome e uma classe Aluno com os mesmos atributos da classe Pessoa porém com Média e Faltas, percebeu que podemos fazer Aluno herdar Pessoa?

Devemos, no entanto, nos atentar a não violar este princípio, principalmente se:

Sobrescrever/implementar um método que não faz nada.
Retornar tipos e valores diferentes da classe pai.

Por exemplo, se na classe pai, cpf retorna String, na classe filho, cpf não pode retornar um Long. Pense como se os métodos da classe pai fosse um contrato de polimorfismo para a classe filha.

De fato, foi um exemplo bem razo, vamos tentar pensar em algo mais usual no dia a dia, como em midia sociais.

Vamos a seguinte classe pai:


public abstract class MediaSocial {
    void chamadaEmGrupo() {
        // Faça algo
    }

    void publicarPost() {
        // faça algo
    }

    void criarGrupos () {
        // faça algo
    }

    void chatComAmigo() {
        // faça algo
    }
}

Vemos que temos uma classe chamada Media SOcial que tem todos as funcionalidades de uma rede social, como o facebook correto?

public class Facebook extends MediaSocial{

    void chamadaEmGrupo() {
        // Faça algo
    }

    void publicarPost() {
        // faça algo
    }

    void criarGrupos () {
        // faça algo
    }

    void chatComAmigo() {
        // faça algo
    }
}

Podemos observar que o facebook implementa todos os métodos da classe MediaSocial, portanto não há violação do principio, pois um pode substituir o outro sem riscos de quebra de contrato.

Agora e se o Whatsapp herdasse Social Media?

public class Whatsapp extends MediaSocial{

        void chamadaEmGrupo() {
            // Faça algo
        }

        void publicarPost() {
            // faça algo
        }

        void criarGrupos () {
            // faça algo
        }

        void chatComAmigo() {
            // faça algo
        }
}

Podemos notar que Whatsapp não tem Publicação de Postagens, então... boom! Portanto, a classe filha whatsapp não substitui a classe pai. Então não segue o principio do LSP

Mas como podemos resolver isso? Vou te mostrar na apresentação da letrinha I (Interface Segregation) do SOLID logo abaixo:

** Obs: Lembrando que, se possível evite fazer usos de Herança, use e abuse de interfaces, Assim como outros princípios do SOLID, o LSP pode se tornar um antipadrão — o que significa que, às vezes, a complexidade adicional não vale a compensação. Exceto em certos casos **

Interface Segregation

Você percebeu, que no exemplo acima, a classe abstrata MediaSocial está implementando trocentos métodos fazendo com que, Whatsapp, Instagram e outras redes sociais não possam implementá-la devida a quantidade de método presente nesse recurso?

Então vamos segregar as interfaces e deixar a parada mais bonita e usável.

Primeiro, vamos arrancar fora essa classe MediaSocial e criar uma interface chamada MediaSocial

interface MediaSocial {
    void chatComAmigo();
    void chamadaDeVoz();
}

Essa interface, ela possui apenas uma responsabilidade, que se trata dos chats privados

Outra interface chamada MediaGrupo:

interface MediaGrupos {
    void chamadaEmGrupo();
    void criarGrupos ();
}

Que possui responsabilidades de Grupos de pessoas.

e outra interface chamada MediaFeed:

interface MediaFeed {
    void publicarPost();
    void verPosts();
}

Que é responsável pelo Feed de noticias das pessoas.

Agora, vamos ajustar as classes Facebook e Whatsapp:

public class Facebook implements MediaSocial, MediaGrupos, MediaFeed{

    @Override
    public void publicarPost() {

    }

    @Override
    public void verPosts() {

    }

    @Override
    public void chamadaEmGrupo() {

    }

    @Override
    public void criarGrupos() {

    }

    @Override
    public void chatComAmigo() {

    }

    @Override
    public void chamadaDeVoz() {

    }
}

Como o Facebook possui todas as funções das interfaces que segregamos, ele implementará todas, Já o whatsapp:

public class Whatsapp implements MediaGrupos, MediaSocial{

        @Override
        public void chamadaEmGrupo() {

        }

        @Override
        public void criarGrupos() {

        }

        @Override
        public void chatComAmigo() {

        }

        @Override
        public void chamadaDeVoz() {

        }
}

Só implementará DUAS interfaces, pois whatsapp não tem Feed de noticias.

Percebeu o ganho e abstração que tivemos implementando esse principio? Um dos melhores principios para sua vida!!

Dependency Inversion

Dependency Inversion basicamente diz que é pra você não depender de uma classe concreta e sim de uma abstração, Módulos de Alto nível não devem depender de módulos de baixo nível, ambos devem depender de abstração.

Bom, vamos criar uma classe que simula um pagamento, que teremos a opção de: Boleto Bancario, Cartões de crédito e débito.

public class Payment {
    private CartaoCredito cartaoCredito;
    private BoletoBancario boletoBancario;
    private DebitoCartao debitoCartao;

    public Payment(CartaoCredito cartaoCredito, BoletoBancario boletoBancario, DebitoCartao debitoCartao) {
        this.cartaoCredito = cartaoCredito;
        this.boletoBancario = boletoBancario;
        this.debitoCartao = debitoCartao;
    }

    public void doPayment() {
        // FAz o pagamento 
    }
}

Do jeito que estamos fazendo, estamos usando injeção de dependência, isso é legal, mas fora isso, segundo o principio DIP, nossa classe está ERRADA DEMAIS, pois note, que a classe de alto nível Payment está dependendo de outras 3 classes concretas, CartaoCredito, BOletoBancario e DebitoCartao, lembra? não podemos depender de implementações e sim de abstrações...

Portanto, vamos criar uma interface chamada PaymentInterface

public interface PaymentInterface {
    void doSomething(double valor);
}

E agora vamos fazer com que as 3 classes de meios de pagamento implementem essa interface.


public class DebitoCartao implements PaymentInterface{
    @Override
    public void doSomething(double valor) {
        System.out.println("Pagamento feito no débito, valor: " + valor);
    }
}

e faremos essa implementação para todos os outros.

Agora na nossa classe Payment, vamos refatorá-la para atender ao DIP.


public class Payment {
    private PaymentInterface meioPagamento;

    public Payment(PaymentInterface meioPagamento) {
        this.meioPagamento = meioPagamento;
    }

    public void doPayment(double valor) {
        meioPagamento.doSomething(valor);
    }
}

Notou que agora estamos dependendo de uma Interface ao invés de uma implementação concreta? dessa forma conseguiremos fazer nossos pagamentos sem nos importar com a implementação de cada Classe de baixo nível (Boleto, Crédito e Débito)

vamos fazer o teste usando uma classe que instancia Payment e faz o fluxo:

public class Program {
    public static void main(String[] args) {
        PaymentInterface debito = new DebitoCartao();
        Payment pagamento = new Payment(debito);

        pagamento.doPayment(1200);
    }
}

Agora no Crédito, usando a mesma lógica:

public class Program {
    public static void main(String[] args) {
        PaymentInterface credito = new CartaoCredito();
        Payment pagamento = new Payment(credito);

        pagamento.doPayment(1200);
    }
}

Lembre-se, dependa sempre de abstrações(interface) e não de implementações (classes concretas)

Até a próxima :)

Engenharia de Software #01 - Os processos por trás da Engenharia

Pedro — Sun, 13 Aug 2023 18:05:56 +0000

Primeiro artigo da série de artigos "Engenharia de Software", no qual eu pretendo trazer uma série de artigos relacionados a Engenharia de software como um todo, nesse eu trago os conceitos por trás dos modelos que utilizamos hoje em dia para o ciclo de vida do software.

O que é Engenharia de Software

Engenharia de Software se dedica à aplicação de princípios, métodos e técnicas para o desenvolvimento de software de forma sistemática e controlada. O objetivo é criar sistemas de software de alta qualidade, confiáveis, eficientes e que atendam às necessidades dos usuários.

Essa área abrange todo o ciclo de vida do desenvolvimento de software, desde a concepção e especificação dos requisitos até a manutenção e evolução do sistema após a sua implantação. Algumas das principais atividades da engenharia de software incluem:

Análise de requisitos: Entender as necessidades e expectativas dos usuários para definir os recursos e funcionalidades que o software deve ter
Projeto de software: Definir a arquitetura e a estrutura do sistema, bem como o detalhamento dos componentes e módulos que serão desenvolvidos.
Codificação: Implementar o software com base no projeto e nas especificações definidas anteriormente.
Testes de software: Verificar se o software funciona corretamente, identificar e corrigir falhas e garantir que ele atenda aos requisitos estabelecidos.
Implantação: Colocar o software em funcionamento no ambiente em que será utilizado pelos usuários.
Manutenção: Realizar ajustes, correções e melhorias no software após sua implantação para garantir seu bom funcionamento ao longo do tempo.

Processos de Software

É um conjunto de atividades relacionadas que levam à produção um produto de software.

Um processo de software bem definido proporciona uma abordagem sistemática para a criação de software de qualidade, controlando riscos e custos, melhorando a produtividade e facilitando a comunicação e colaboração entre os membros da equipe de desenvolvimento.

Modelos de Processo de Software

Modelo Cascata: É um processo linear e sequencial, no qual cada fase deve ser concluída antes de avançar para a próxima. As etapas incluem: requisitos, projeto, implementação, testes e manutenção.
Modelo Incremental: Divide o desenvolvimento do software em incrementos menores, permitindo que cada incremento adicione funcionalidades e seja integrado aos incrementos anteriores de forma iterativa.
Modelo em Espiral: Combina elementos do modelo cascata com a abordagem iterativa, incluindo ciclos de avaliação de riscos e planejamento de atividades.
Modelo Ágil: É uma abordagem colaborativa e iterativa que valoriza a entrega contínua de software funcional e a adaptação às mudanças dos requisitos ao longo do projeto.

Rational Unified Process RUP

O IBM Rational Unified Process (RUP) é um processo de desenvolvimento de software baseado em um modelo iterativo e incremental. Ele é uma das metodologias mais conhecidas e utilizadas no âmbito da Engenharia de Software. O RUP foi criado pela Rational Software Corporation, que foi adquirida pela IBM em 2003, e desde então, passou a ser conhecido como IBM RUP.

O RUP é caracterizado por sua abordagem iterativa, ou seja, o desenvolvimento do software é dividido em várias iterações, e em cada iteração, uma parte do software é projetada, implementada, testada e entregue. Essas iterações são períodos de tempo relativamente curtos, geralmente de 2 a 6 semanas, e permitem que os resultados intermediários sejam obtidos e revisados periodicamente, garantindo maior controle e adaptação às mudanças durante o processo.

Os princípios fundamentais do IBM RUP incluem:

Foco nos Casos de Uso: O RUP baseia o desenvolvimento no entendimento das necessidades dos usuários através de Casos de Uso, que descrevem as interações entre o sistema e seus usuários, permitindo uma abordagem centrada no usuário.
Arquitetura Centrada: O RUP coloca uma forte ênfase na definição e no desenvolvimento de uma arquitetura sólida e bem estruturada para o software, o que facilita a compreensão do sistema como um todo e reduz riscos e problemas futuros.
Gestão de Mudanças: O processo RUP reconhece a natureza dinâmica do desenvolvimento de software e oferece uma abordagem para gerir mudanças de requisitos, prioridades e outras variáveis que possam surgir durante o projeto.
Componentização: O RUP promove a reutilização de componentes de software sempre que possível, facilitando a manutenção e evolução do sistema.

O IBM RUP é composto por fases, disciplinas e papéis que fornecem uma estrutura para orientar o desenvolvimento do software. As principais fases do RUP são:

Concepção (Inception): Nesta fase, os requisitos são analisados, os objetivos do projeto são definidos e a viabilidade técnica e financeira é avaliada.
Elaboração (Elaboration): Fase na qual a arquitetura é projetada, os riscos são identificados e a base para o desenvolvimento é estabelecida.
Construção (Construction): É a fase de implementação do software, onde as funcionalidades são desenvolvidas iterativamente.
Transição (Transition): Nesta fase, o software é testado, implantado e entregue aos usuários.

O RUP também define disciplinas, que são conjuntos de atividades relacionadas que abordam aspectos específicos do desenvolvimento do software, como requisitos, análise e design, implementação, testes, entre outros.

Os papéis no RUP incluem o Gerente de Projeto, o Analista de Requisitos, o Arquiteto, o Desenvolvedor, o Testador, entre outros, cada um com suas responsabilidades bem definidas no processo.

É importante notar que o RUP pode ser adaptado para atender às necessidades específicas de um projeto e de uma organização, tornando-o uma metodologia flexível e amplamente aplicável em diferentes contextos de desenvolvimento de software.

Métodos e Desenvolvimento Ágil

Em meados de 1970 quando a engenharia de software era quase inexistente, houve a chamada "Crise do software" na qual as equipes de Software tinham problemas como Orçamento, prazo, qualidade, requisitos, manutenabiliade dentre outras coisas e daí surgiu a necessidade de evolução para sanar esses problemas e daí surgiiu a Engenharia de software Tradicional no qual trata com mais cautela o planejamento, qualidade, uso de métodos de análise e design e o processo de desenvolvimento se tornou mais rigoroso e controlado.

E em meados de 2000 surge a engenharia de software ágil.

Métodos ágeis e Desenvolvimento Ágil são termos relacionados que se referem a uma abordagem de desenvolvimento de software que prioriza a flexibilidade, a colaboração e a entrega contínua de valor aos clientes. Os Métodos Ágeis são uma resposta às limitações de abordagens tradicionais de desenvolvimento, como o modelo cascata, que muitas vezes se mostraram rígidas e pouco adaptáveis às mudanças frequentes nos requisitos e no ambiente de negócios.

Manifesto Ágil 2001:

"Estamos descobrindo maneiras melhores de desenvovler software, fazendo-os nós mesmos e ajudando os outros a fazerem o mesmo. Atrave´s deste trabalho, passamos a valorizar:

Individios e Interações mais do que processos e Ferramentas
Software em funcionamento mais que documentação pesada
Colaboração com o cliente e menos contratos e negociações
Rápida resposta a mudança mais que seguir planos já definidos

Ou seja, mesmo havendo valor nos itens à direnta, valorizamos mais os itens a esquerda"

Engenharia de Software ágil:

Valorização das Pessoas e da Interação: Reconhecem que indivíduos talentosos e colaborativos são a chave para o sucesso do projeto, incentivando a comunicação face a face entre os membros da equipe.
Entrega Contínua de Software Funcional: Priorizam a entrega de incrementos de software funcional em curtos períodos de tempo, geralmente em algumas semanas, permitindo que o cliente comece a obter valor rapidamente.
Colaboração com o Cliente: Envolvem os clientes e usuários finais durante todo o processo de desenvolvimento para garantir que o software atenda às suas necessidades e expectativas.
Resposta a Mudanças: Aceitam que os requisitos e prioridades podem mudar ao longo do projeto e estão preparados para se adaptar a essas mudanças de forma eficiente.
Auto-organização da Equipe: Permitem que as equipes de desenvolvimento se auto-organizem e tomem decisões relacionadas ao trabalho que realizam.

Alguns dos métodos ágeis mais conhecidos incluem Scrum, Kanban, Extreme Programming (XP) e Lean Software Development, entre outros. Cada um possui suas próprias práticas específicas, mas todos compartilham a ênfase na colaboração, comunicação frequente, feedback contínuo e entrega incremental de software.

O Desenvolvimento Ágil é o processo de aplicar os princípios e práticas dos Métodos Ágeis em um projeto de desenvolvimento de software específico. Nesse contexto, a equipe trabalha em iterações curtas e focadas, geralmente chamadas de sprints (no caso do Scrum), onde planejam, desenvolvem, testam e entregam funcionalidades incrementais em intervalos regulares.

Ao adotar o Desenvolvimento Ágil, as equipes podem responder rapidamente a mudanças nos requisitos, identificar e resolver problemas com mais agilidade e garantir que o software entregue seja mais alinhado às necessidades dos clientes e do mercado.

Essa abordagem é particularmente eficaz em projetos complexos e dinâmicos, onde os requisitos podem evoluir à medida que o projeto avança. O Desenvolvimento Ágil promove um ambiente de trabalho colaborativo, transparente e focado no cliente, permitindo que a equipe de desenvolvimento alcance resultados com mais eficiência e qualidade.

Engenharia de Requisitos

A Engenharia de Requisitos é uma disciplina fundamental dentro da Engenharia de Software, responsável por identificar, analisar, documentar e gerenciar os requisitos de um sistema de software. Os requisitos são as funcionalidades, características e restrições que o software deve atender para satisfazer as necessidades dos usuários e das partes interessadas.

O processo de Engenharia de Requisitos envolve várias atividades importantes:

Elicitação de Requisitos: Nesta fase, os engenheiros de requisitos interagem com os stakeholders (clientes, usuários finais, gerentes de projeto, etc.) para entender suas necessidades e expectativas em relação ao sistema. Isso pode ser feito por meio de entrevistas, workshops, questionários ou outras técnicas de comunicação.
Análise e Documentação de Requisitos: Após a elicitação, os requisitos são analisados, refinados e documentados de forma clara e precisa. A documentação inclui descrições detalhadas dos requisitos, casos de uso, diagramas de fluxo e outras técnicas para facilitar a compreensão do que o sistema deve fazer.
Gerenciamento de Requisitos: Os requisitos estão sujeitos a mudanças ao longo do ciclo de vida do projeto. O gerenciamento de requisitos envolve o controle de alterações, rastreamento de versões e garantia de que todos os requisitos sejam rastreáveis e consistentes ao longo do projeto.
Validação e Verificação de Requisitos: Antes de prosseguir para a próxima fase do projeto, os requisitos são revisados e validados para garantir que eles sejam compreensíveis, completos, consistentes e atendam às expectativas dos stakeholders. A verificação visa confirmar que os requisitos estão bem escritos e são tecnicamente viáveis.
Negociação de Requisitos: Em alguns casos, os stakeholders podem ter requisitos conflitantes ou difíceis de atender devido a restrições de recursos ou tecnológicas. A negociação de requisitos envolve encontrar soluções equilibradas que satisfaçam a maioria das partes interessadas.
Rastreabilidade de Requisitos: É importante rastrear a origem e o destino de cada requisito ao longo do projeto. A rastreabilidade ajuda a garantir que todos os requisitos sejam atendidos e que as mudanças tenham um impacto controlado em todo o sistema.

A Engenharia de Requisitos é um processo contínuo e iterativo que acompanha o ciclo de vida completo do desenvolvimento de software. Uma boa engenharia de requisitos é fundamental para o sucesso do projeto, pois estabelece as bases para o projeto e desenvolvimento do software, garantindo que o sistema entregue atenda às necessidades dos usuários e clientes.

Casos de Uso

"Um caso de uso especifica o comportamento de um sistema (ou parte), e é uma descrição de um conjunto de sequências de ações para produzir um resultado observável ao valor de um ator"

Usamos casos de uso para captar o comportamento pretendido de um sistema, sem especificar como esse comportamento é implementado

Aqui está um diagrama de caso de uso simples para o sistema de gerenciamento de tarefas (to-do list) com dois casos de uso: "Adicionar Tarefa" e "Visualizar Tarefas".

            +----------------+
            |     Usuário    |
            +-------+--------+
                    |
                    v
            +----------------+
            | Gerenciar      |
            | Tarefas        |
            +-------+--------+
                    |
           +--------+---------+
           |                  |
  +-----------------+  +------------------+
  | Adicionar Tarefa|  | Visualizar Tarefas|
  +-----------------+  +------------------+

Neste diagrama, temos dois atores principais: "Usuário" e "Gerenciar Tarefas". O ator "Usuário" representa qualquer usuário do sistema que interage com as funcionalidades do sistema. O ator "Gerenciar Tarefas" é um ator fictício que representa o sistema em si, pois não é uma pessoa, mas sim a parte do sistema responsável por gerenciar as tarefas.

Os dois casos de uso principais são representados como elipses retangulares no diagrama: "Adicionar Tarefa" e "Visualizar Tarefas". O caso de uso "Adicionar Tarefa" é uma funcionalidade que permite ao usuário adicionar uma nova tarefa ao sistema. O caso de uso "Visualizar Tarefas" permite ao usuário visualizar todas as tarefas existentes no sistema.

O ator "Usuário" interage com o caso de uso "Adicionar Tarefa" e "Visualizar Tarefas" através do ator "Gerenciar Tarefas". Isso significa que o caso de uso "Gerenciar Tarefas" é responsável por coordenar as interações do usuário com os casos de uso "Adicionar Tarefa" e "Visualizar Tarefas".

Esse é apenas um exemplo simplificado de um diagrama de caso de uso. Em sistemas reais, o diagrama de caso de uso pode ser mais complexo, com vários atores e casos de uso, além de relações adicionais entre eles. O diagrama de caso de uso é uma ferramenta poderosa para visualizar e comunicar as funcionalidades do sistema e as interações com os usuários.

Diagrama de Sequência

Vamos criar um diagrama de sequência simples para ilustrar a interação entre o ator "Usuário" e o caso de uso "Adicionar Tarefa" no sistema de gerenciamento de tarefas (to-do list). O diagrama de sequência mostra a ordem das mensagens trocadas entre os objetos envolvidos na execução do caso de uso.

+-------------------+         +-----------------+       +-------------------+
|     Usuário       |         | Gerenciar       |       |     Tarefa        |
|                   |         | Tarefas         |       |                   |
+-------------------+         +-----------------+       +-------------------+
        |                            |                          |
        |   Seleciona a opção        |                          |
        |   "Adicionar Tarefa"      |                          |
        |-------------------------->|                          |
        |                            |                          |
        |                            | Exibe formulário        |
        |                            | de criação de tarefa   |
        |                            |------------------------>|
        |                            |                          |
        |                            |                          |
        | Preenche os campos        |                          |
        | obrigatórios (título e    |                          |
        | data de vencimento)       |                          |
        |-------------------------->|                          |
        |                            |                          |
        |                            |    Valida os campos     |
        |                            |    preenchidos         |
        |                            |<------------------------|
        |                            |                          |
        |                            |    Cria a tarefa       |
        |                            |    com as informações  |
        |                            |    fornecidas          |
        |                            |    pelo usuário        |
        |                            |------------------------>|
        |                            |                          |
        |                            | Exibe mensagem de      |
        |                            | confirmação           |
        |                            |<------------------------|
        |                            |                          |

Neste diagrama de sequência, temos três objetos envolvidos na interação: "Usuário", "Gerenciar Tarefas" e "Tarefa". A seta "->" indica a direção das mensagens trocadas entre os objetos.

O diagrama começa com o "Usuário" selecionando a opção "Adicionar Tarefa". Em seguida, o "Gerenciar Tarefas" exibe o formulário de criação de tarefa para o "Usuário". O "Usuário" preenche os campos obrigatórios, e o sistema valida os campos preenchidos. Após a validação, o "Gerenciar Tarefas" cria a tarefa com as informações fornecidas e exibe uma mensagem de confirmação para o "Usuário".

Esse é apenas um exemplo simplificado de um diagrama de sequência. Em sistemas reais, o diagrama de sequência pode ser mais complexo, com mais objetos envolvidos e interações mais detalhadas. O diagrama de sequência é uma ferramenta valiosa para entender a ordem das interações entre os objetos e a troca de mensagens durante a execução de um caso de uso.

Requisitos Funcionais

Os requisitos funcionais descrevem as funcionalidades específicas que o sistema deve oferecer, ou seja, o que o software deve fazer para satisfazer as necessidades dos usuários. Eles detalham as principais ações, tarefas e operações que o sistema deve ser capaz de executar. Os requisitos funcionais geralmente são descritos através de ações verbais, como "adicionar", "editar", "excluir", "visualizar", "calcular", entre outros.

Vamos pensar em alguns requisitos funcionais para o sistema de gerenciamento de tarefas (to-do list):

Requisitos Funcionais:

RF001 - Adicionar Tarefa: O sistema deve permitir que o usuário adicione uma nova tarefa, fornecendo um título, uma descrição (opcional) e uma data de vencimento.

RF002 - Visualizar Tarefas: O sistema deve permitir que o usuário visualize todas as tarefas existentes, exibindo o título, descrição, data de vencimento e status (concluída ou pendente).

RF003 - Editar Tarefa: O sistema deve permitir que o usuário edite os dados de uma tarefa existente, incluindo título, descrição e data de vencimento.

RF004 - Excluir Tarefa: O sistema deve permitir que o usuário exclua uma tarefa existente.

RF005 - Marcar Tarefa como Concluída: O sistema deve permitir que o usuário marque uma tarefa como concluída, alterando o status da tarefa para "concluída".

Requisitos Não Funcionais

Os requisitos não funcionais definem características e atributos do sistema que não estão diretamente relacionados com as funcionalidades específicas, mas são igualmente importantes para o seu desempenho, qualidade e usabilidade. Eles se concentram em aspectos como desempenho, segurança, usabilidade, confiabilidade e portabilidade do sistema.

Vamos pensar em alguns requisitos Não Funcionais para o sistema de gerenciamento de tarefas (to-do list):

Requisitos Não Funcionais:
RNF001 - Usabilidade: O sistema deve possuir uma interface intuitiva e fácil de usar, permitindo que usuários com diferentes níveis de habilidade possam interagir com o sistema de forma eficiente.

RNF002 - Desempenho: O sistema deve ser responsivo e rápido na execução das operações, garantindo tempos de resposta adequados mesmo em períodos de alta carga de usuários.

RNF003 - Segurança: O sistema deve garantir a proteção dos dados dos usuários e das tarefas, evitando acesso não autorizado e mantendo a confidencialidade e integridade das informações.

RNF004 - Confiabilidade: O sistema deve ser confiável, minimizando a ocorrência de erros e falhas, e garantindo que as tarefas adicionadas pelos usuários sejam devidamente armazenadas e recuperadas.

RNF005 - Portabilidade: O sistema deve ser projetado para ser executado em diferentes plataformas e dispositivos, como computadores, tablets e smartphones, suportando diversos sistemas operacionais e navegadores.

Esses requisitos são apenas um exemplo simplificado para ilustrar a ideia de requisitos funcionais e não funcionais. Em projetos reais, a lista de requisitos geralmente é mais extensa e detalhada, sendo definidos com base nas necessidades e expectativas dos usuários e nas restrições do ambiente em que o sistema será implantado.

Devops

DevOps é uma cultura, conjunto de práticas e abordagem para a integração e colaboração entre as equipes de desenvolvimento de software (Dev) e operações de TI (Ops). A palavra "DevOps" é uma junção dos termos "Development" (Desenvolvimento) e "Operations" (Operações).

O objetivo principal do DevOps é eliminar barreiras e melhorar a comunicação entre desenvolvedores e profissionais de operações, de modo a criar um ambiente de trabalho colaborativo e ágil. Essa colaboração entre as equipes permite a entrega mais rápida e frequente de software, além de garantir maior estabilidade e confiabilidade nos ambientes de produção.

Algumas das principais características e práticas associadas ao DevOps incluem:

Automação: O uso extensivo de automação de processos, como compilação, testes, implantação e provisionamento de infraestrutura, para eliminar tarefas manuais repetitivas e reduzir erros humanos.
Integração Contínua (CI): A prática de integrar o código produzido por diferentes desenvolvedores em um repositório compartilhado várias vezes ao dia. Isso permite detectar e corrigir problemas de integração mais cedo no ciclo de desenvolvimento.
Entrega Contínua (CD): A extensão da Integração Contínua, onde o objetivo é automatizar o processo de implantação do software em ambientes de produção a qualquer momento que seja necessário, tornando as implantações mais frequentes e confiáveis.
Monitoramento e Feedback: A coleta de métricas e monitoramento constante do desempenho do sistema em produção para identificar problemas, garantir a qualidade e responder rapidamente a falhas.
Cultura de Colaboração: Fomentar uma cultura de colaboração, responsabilidade compartilhada e comunicação aberta entre desenvolvedores, operadores e outras partes interessadas.
Infraestrutura como Código (IaC): A prática de gerenciar a infraestrutura de TI (servidores, redes, etc.) através de código, permitindo provisionamento rápido, consistente e automatizado de ambientes.

Ao adotar a cultura e as práticas do DevOps, as organizações podem acelerar o desenvolvimento de software, melhorar a qualidade do produto final, aumentar a eficiência operacional e responder com mais rapidez às demandas do mercado e dos usuários. O DevOps se tornou uma abordagem essencial para empresas que buscam agilidade e competitividade em seus processos de desenvolvimento e entrega de software.

How to generate a docker image of your Spring Boot application

Pedro — Sun, 31 Oct 2021 22:34:49 +0000

What is Docker?

Docker is a set of platform products as services that uses virtualizations on Operational System level for giving us softwares calleds "containers". The containers are isolated from each other and a group yours softwares, libraries and configuration archives.

Create account Docker Hub
Do docker download on you pc: download

now, with your docker hub account, lets to create a repository!

Well, now we have a public repository

now, do login into the docker hub app, if you use linux, use the command below on terminal:

docker login -u {you_username}, tap enter and write your password.

now, you should to create an archive called "Dockerfile" in root directory, and write those commands:

FROM openjdk:15
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*", "com.spiet.aws_spring01.AwsSpring01Application"]

obs: change the com.spiet.Aws... to your package with initialization class

Editing build.gradle

First, we need to add the build script, to make build before up the application to image

buildscript {
    ext {
        springBootVersion = '2.5.6'
    }

    repositories {
        mavenCentral()
        maven {
            url "https://plugins.gradle.org/m2/"
        }
    }

    dependencies {
        classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
        classpath("gradle.plugin.com.palantir.gradle.docker:gradle-docker:0.22.2")
    }
}

obs: see that i need the dependencie palantir.gradle.docker in buildScript, so, in plugin sessons below, we need to add
id 'com.palantir.docker' version '0.22.2' too.

then, below in group:

change the group to your dockerId in docker hub.

NEXT, below, we need to add a bootJar with repository informations and mainClass of application:

bootJar {
    baseName = 'aws_training_01'
    version = '1.0.0'
    mainClassName = "com.pedrospiet.spring01.AwsSpring01Application"
}

now, we are going to add the tasks that make our project generated the docker image


task unpack(type: Copy) {
    dependsOn bootJar
    from(zipTree(tasks.bootJar.outputs.files.singleFile))
    into("build/dependency")
}

docker {
    name "${project.group}/${bootJar.baseName}"
    tags "${bootJar.version}"
    copySpec.from(tasks.unpack.outputs).into("dependency")
    buildArgs(['DEPENDENCY': "dependency"])
}

It Works

Running image in a container on Intelij IDEA

First press ALT + 8

click on run

In image session, we can found our image, so click with right button and go to "Create Container"

configure the ports:

go to APPLY and RUN

now we can test in insomnia