From 2c8e895aa8201323b1584f2aae526904d84a0417 Mon Sep 17 00:00:00 2001 From: Lourenco Matos <80357060+Lourencom@users.noreply.github.com> Date: Fri, 26 Apr 2024 12:56:07 +0000 Subject: [PATCH] [ES] Add content skeleton (#1024) --- content/es/0003-code-coverage.md | 2 + content/es/0004-refactoring-and-reuse.md | 75 +++++++++++++ content/es/0005-software-design.md | 91 ++++++++++++++++ content/es/0006-software-architecture.md | 59 +++++++++++ content/es/0007-peaa.md | 129 +++++++++++++++++++++++ 5 files changed, 356 insertions(+) create mode 100644 content/es/0004-refactoring-and-reuse.md create mode 100644 content/es/0005-software-design.md create mode 100644 content/es/0006-software-architecture.md create mode 100644 content/es/0007-peaa.md diff --git a/content/es/0003-code-coverage.md b/content/es/0003-code-coverage.md index 28f4fe78..dd80d108 100644 --- a/content/es/0003-code-coverage.md +++ b/content/es/0003-code-coverage.md @@ -23,6 +23,8 @@ vantagens e desvantagens: - [**_Condition Coverage_**](color:yellow) - [**_Path Coverage_**](color:blue) + + ## Statement Coverage :::warning[Secção Incompleta] diff --git a/content/es/0004-refactoring-and-reuse.md b/content/es/0004-refactoring-and-reuse.md new file mode 100644 index 00000000..1b8a84e4 --- /dev/null +++ b/content/es/0004-refactoring-and-reuse.md @@ -0,0 +1,75 @@ +--- +title: Refactoring e Reutilização de Software +description: >- + Refatorização e Reutilização de Software +path: /es/refactoring +type: content +--- + +# Refactoring e Reutilização de Software + +```toc + +``` + +## Reutilização de Software + +Software pode ser reutilizado de várias formas: + +**Libraries**: adaptam através de parametrização, reutilizam código + +**Frameworks**: adaptam através de extensão, reutilizam design + +- Em _libraries_, o nosso código invoca o da _library_, que por sua vez executa e devolve controlo ao nosso programa + +- No entanto, em _frameworks_, ao reutilizarmos o design, utilizamos a framework como um esqueleto do programa, no qual o nosso código é incorporado. Assim, damos o _flow control_ do programa à framework. Este princípio de delegação de controlo à framework é chamado de _Hollywood Principle: "Don't call us, we'll call you"_, embora seja também conhecido como o princípio de inversão de controle (_Inversion of Control_). + +**Code generators**: adaptam através da escrita de modelos e frases de alto nível, geram código e possibilitam _aspect-oriented development_ (e.g. JPA) e _model-driven engineering_ (e.g. OutSystems) + +**Product Lines**: adaptam por seleção e extensão, com módulos comuns e módulos de variação + +**Services**: adaptam através de parametrização, sendo a diferença destes e das bibliotecas, que estes partilham serviços + +## Refactoring (Refatoração) + +### Processo de Refactoring + +As abstrações dependem do contexto, e é difícil desenvolver boas abstraçẽs através de abordagens _top-down_. +Refactoring, é uma abordagem _bottom-up_ para a construção de abstrações a partir de casos de uso de código. + +O processo de refactoring é precedido pelos seguintes passos: + +1. Desenvolver testes para a funcionalidade que vai ser implementada. +2. Foco em implementar a funcionalidade corretamente, sem pensar na estrutura ótima. +3. Quando a funcionalidade estiver corretamente implementada e todos os testes passarem, podemos iniciar o processo de refactoring. + +O processo de refactoring é caraterizado pelo seguinte ciclo: + +1. Mudar a estrutura +2. Testar + +:::tip[NOTA IMPORTANTE] + +- A refatoração é um processo incremental. É importante que se façam mudanças pequenas de cada vez, para que o código **NUNCA** deixe de funcionar. + +::: + +### Tipos de Refactoring + +:::warning[Secção Incompleta] +Esta secção encontra-se incompleta. Procuram-se contribuidores. +::: + +- **Test Driven Development** + +- **Litter-Pickup** + +- **Comprehension** + +- **Preparatory**: "make the change easy, then make the easy change" + +- **Planned** + +- **Long-Term**: substituir uma abstração com uma nova interface + + diff --git a/content/es/0005-software-design.md b/content/es/0005-software-design.md new file mode 100644 index 00000000..fe6a0d56 --- /dev/null +++ b/content/es/0005-software-design.md @@ -0,0 +1,91 @@ +--- +title: Design de Software +description: >- + Princípios e Padrões do Desenho de Software. +path: /es/software-design +type: content +--- + +# Design de Software + +```toc + +``` + +O desenho de software é uma parte crucial no desenvolvimento de software. +Alguns dos objetivos são facilitar a manutenção e evolução do software ao longo do tempo. + +O custo de mudança é altamente impactado pela localidade e propagação da mudança. +É mais fácil mudar 100 linhas num módulo do que 1 linha em 100 módulos. + +Então, é necessário ficarmos familiarizados com dois conceitos cruciais de bom desenho de software: + +**Coesão**, ou _Cohesion_, é a métrica que avalia a localidade da mudança. +Um módulo altamente coeso, probabilisticamente falando, terá uma localidade de mudança alta. + +**Ligação**, ou _Coupling_, é a métrica que avalia a propagação da mudança. +Um módulo com baixa ligação, probabilisticamente falando, terá menor propagação de mudanças. + +Bom desenho de software deve ser desenvolvido com as seguites propriedades: + +- Alta Coesão -> Aumentar localidade de mudança +- Baixa Ligação -> Diminuir propagação de mudança + +## Princípios de Design de Software + +Os princípios de desenho de software **SOLID** são: + +**S**ingle Responsibility: Um módulo deve ter uma única responsabilidade. + +**O**pen-Closed: Aberto a extensão, Fechado a modificação. + +**L**iskov's Substitution Principle: Deve ser possível substituir completamente uma subclasse pelas suas abstrações sem gerar erros. + +**I**nterface Segregation: Clientes devem usar interfaces mínimas que têm apenas o estritamente necessário para a sua interação. + +**D**ependency Inversion: Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. + +## Padrões de Design de Software + + + +### Command + +_Invoker_ interage com uma abstração de um comando. O cliente define um comando concreto, que implementa a interface abstrata do comando. + +Propriedades: + +- Baixa ligação entre o _invoker_ e cada comando concreto +- Fácil de extender com novos tipos de comandos +- Comandos concretos são altamente + +### Template Method + +Define o esqueleto do programa num algoritmo e delega alguns passos para as subclasses. Mantém a estrutura do algoritmo, com a liberdade de poder alterar os seus passos. + +Propriedades: + +- Ligação alta entre subclasses e superclass devido à estrutura do algoritmo +- Estrutura do algoritmo é coesa na superclasse +- Partes do algoritmo são coesas nas subclasses + +### Composite + +Compõe objetos em estruturas de árvore, com maior liberdade na representação de hierarquias. + +Propriedades: + +- Baixa ligação entre o cliente e o _composite_, pois o cliente depende de uma interface comum a todos os membros +- Membros usam a mesma interface na comunicação, e é fácil extender com novos tipos de membros +- Alta coesão visto que cada membro contém resposabilidades associadas à sua função + +### State + +Encapsula comportamentos variados no mesmo objeto, com base num estado interno. +Um _State_ é uma interface abstrata usada pelo contexto, e cada _Concrete State_ é uma subclasse desta abstração. + +Propriedades: + +- Baixa ligação entre o contexto e o _State_ +- Um _Concrete State_ tem uma coesão alta relativamente ao seu set de operações +- Operações têm baixa coesão, visto que estão divididas pelos múltiplos possíveis _Concrete States_ diff --git a/content/es/0006-software-architecture.md b/content/es/0006-software-architecture.md new file mode 100644 index 00000000..7a9f2fb0 --- /dev/null +++ b/content/es/0006-software-architecture.md @@ -0,0 +1,59 @@ +--- +title: Arquitetura de Software +description: >- + Arquitetura de Software, Padrões Arquiteturais, Arquiteturas de Aplicações, Engenharia de Requisitos +path: /es/software-architecture +type: content +--- + +# Arquitetura de Software + +```toc + +``` + +:::warning[Secção Incompleta] +Esta secção encontra-se incompleta. Procuram-se contribuidores. +::: + +A arquitetura de software tem o objetivo de fazer um design de alto nível do desenvolvimento de software. Deve demonstrar as qualidades do sistema e satisfazer os requisitos dos stakeholders. + +Pode ser vista de diferentes perspetivas: + +- Lógica (Logical view) +- Física (Physical view) +- Desenvolvimento (Development view) +- Processo (Process view) + +## Padrões Arquiteturais + +**MVC** + +**Layered** + +**Repository** + +**Client-Server** + +**Pipe and Filter** + +## Arquiteturas de Aplicações + +**Transaction Processing Sytems** + +**Information Systems** + +**Language Processing Systems** + +## Engenharia de Requisitos + +Qualidades dos Requisitos: + +- Completude (Completeness) +- Consistência (Consistency) +- Mensurabilidade (Measurability) + +### Processo de Engenharia de Requisitos + +1. Elicitação e Análise +2. Validação diff --git a/content/es/0007-peaa.md b/content/es/0007-peaa.md new file mode 100644 index 00000000..30113450 --- /dev/null +++ b/content/es/0007-peaa.md @@ -0,0 +1,129 @@ +--- +title: Padrões de Aplicações Empresariais +description: >- + Padrões de Aplicações Empresariais: Lógica de Domínio, Arquitetura de Fontes de Dados, Object-Relational Structural and Behavioral, Apresentação, Distribuição +path: /es/peaa +type: content +--- + +# Padrões de Aplicações Empresariais + +```toc + +``` + + + +Estes são alguns dos padrões utilizados no desenvolvimento de aplicações empresariais. Mais padrões podem ser encontrados no catálogo oficial [Patterns of Enterprise Applications](https://martinfowler.com/eaaCatalog/), sendo que estes estão explicados a fundo no [livro](https://martinfowler.com/books/eaa.html). + +## Domain Logic Patterns + +### Transaction Script + +Organiza a lógica de domínio em transações, em que cada transação está associada a um _request_ do utilizador e trata de uma única apresentação. + +### Domain Module + +Organiza a lógica de domínio numa abordagem orientada a objetos. É caraterizada por objetos de domínio que incorporam tanto lógica de negócio como dados. + +### Service Layer + +Define limites da aplicação através de uma camada de serviços, que define um conjunto de operações/serviços que o utilizador pode executar, coordenando as respostas da aplicação para cada um desses serviços. + +## Data Source Architectural Patterns + +### Table Data Gateway + +Objeto que serve de _gateway_ para uma tabela da base de dados. Cada instância deste objeto está responsável pela interação com todas as linhas dessa tabela. + +### Row Data Gateway + +Objeto que serve de _gateway_ para uma linha numa tabela da base de dados. Cada instância deste objeto está responsável pela interação com uma única linha da tabela. + +### Active Record + +Objeto que encapsula uma linha de uma tabela da base the dados, adicionando lógica de domínio a esses dados. + +### Data Mapper + +Uma camada de _mappers_ que associa objetos de domínio com a base de dados, o que promove a independência entre a estrutura do objeto de domínio e a representação deste na base de dados. + +## Object-Relational Behavioral Patterns + +### Unit of Work + +Mantém uma lista de objetos afetados por uma transação, para coordenar a escrita das alterações da transação e resolver problemas de concorrência. + +### Identity Map + +Mapa de identidade que garante que cada objeto só é carregado uma vez. Quando tenta aceder ao objeto, verifica se não foi já carregado para o mapa. + +### Lazy Load + +Objetos que não contém toda a informação necessária, mas sabem como ir buscar, maioritariamente para melhorar a eficiência e evitar carregar objetos de largas dimensões a menos que necessário. + +Existem múltiplas abordagens: + +- **_Lazy Initialization_**: verifica se campo é _null_ quando acede, e se for _null_, carrega-o +- **_Virtual Proxy_**: _proxy_ do objeto real que delega responsabilidade para o objeto real quando algum dos seus campos é acedido +- **_Value Holder_**: encapsula os campos do objeto real com métodos +- **_Ghost_**: objeto real num estado parcial, que carrega todos os campos quando acessado + +## Object-Relational Structural Patterns + +### Identity Field + +Guardar o ID do objeto na base de dados como um dos seus campos, para manter uma identidade entre o objeto em memória e na base de dados. + +### Foreign Key Mapping + +Associa objetos através de uma _foreign key_ que referencia a outra tabela da associação. + +### Association Table Mapping + +Associa objetos criando uma nova tabela que guarda conjuntos de _foreign keys_, em que cada uma referencia uma tabela da associação. + +### Single Table Inheritance + +Representa uma hierarquia de herança com uma única tabela, com colunas para todos os campos de todas as subclasses. Alguns objetos poderão ter colunas a _null_, associadas aos campos que não fazem parte da sua classe concreta. + +### Class Table Inheritance + +Representa uma hierarquia de herança com uma tabela para cada classe. Uma classe concreta pode resultar dos joins das tabelas das várias classes que a compõem. + +### Concrete Table Inheritance + +Representa uma hierarquia de herança com uma tabela para cada classe concreta. + +## Web Presentation Patterns + +### Model-View-Controller (MVC) + +Divide a interface de utilizador em 3 componentes com as suas responsabilidades, o modelo, a vista, e o controlador. +A vista apresenta os dados ao utilizador. +O controlador atualiza o modelo e entrega os dados à vista apropriada. +O modelo contém os dados. + +O utilizador pede uma vista a um controlador. O controlador interage com o modelo, e pede os dados. O modelo devolve os dados ao controlador. O controlador entrega os dados à vista. A vista apresenta os dados ao utilizador. + +### Front Controller + +Um controlador que trata de todos os _requests_. + +Existe um _handler_ que trata de todo o comportamento comum e chama comandos através de uma interface _command_. + +Existem comandos concretos, que definem comportamento específico e herdam da interface _command_. +Cada um destes comandos concretos é chamado pelo _handler_, executa o seu comando concreto e escolhe a vista apropriada para ser apresentada. + + + +## Distribution Patterns + +### Remote Façade + +Fornece uma _coarse-grained interface_ em _fine-grained objects_ para aumentar a eficiência através de uma rede. +É mais eficiente ter menos chamadas remotas mais grosseiras e depois retirar a informação necessária dentro do processo final do que fazer múltiplas chamadas remotas finas. + +### Data Transfer Object (DTO) + +Objeto serializável que serve para transferir dados entre processos de forma prática e eficiente. É um objeto de dados, não é o próprio objeto.