tradeoff, entity, deadlock,polymorphism ...
O vocabulário do desenvolvimento é composto por palavras em inglês que me lembram palavras indígenas. Uma palavra que o significado é uma frase.
Açaí (ïwasa’i): é o fruto que deita água,que chora, que dá sumo.
package - um meio de organizar classes relacionadas no mesmo namespace.
namespace - um contêiner abstrato para um grupo de módulos relacionados, dado um identificador exclusivo. E por aí vai.
Neste artigo listei as principais palavras e termos para você participar das rodinhas de conversas com a turminha do desenvolvimento de software sem ficar com cara de "mim não entendeu".
- abstract - em design orientado a objetos, uma classe que não pode ser instanciada diretamente, mas deve ser subclassificada
- abstract data types - tipos de dados que são definidos pelo seu comportamento em oposição à sua estrutura. Definido pelo desenvolvedor e não pela linguagem de programação
- access modifiers - palavras-chave que controlam quais outras classes podem acessar uma variável ou método em uma classe. Em Java, isso inclui public, protected, private e default.
- abstraction - o ato de simplificar um conceito no contexto. No projeto orientado a objetos, é a simplificação da entidade do mundo real em seus atributos e comportamentos mais importantes para o propósito do software.
- attribute - uma propriedade que o objeto de uma classe deve ter, mesmo que seus valores possam ser diferentes. Por exemplo, dois objetos de aluno têm um atributo de nota, mesmo que um tenha um 'A' e o outro tenha um 'B'.
- behaviours - as ações que um objeto pode realizar
- boundary object - um objeto cuja função é fazer interface com um componente externo, como um usuário ou um sistema adjacente
- class diagram - um diagrama UML para mostrar os comportamentos, atributos, herança e conexões de classes
- code review - revisões sistemáticas de código escrito feitas pela equipe de desenvolvimento. Não apenas para encontrar erros, mas para fazer com que os desenvolvedores usem as mesmas convenções, construções, princípios de design, etc.
- cohesion - descrevendo a complexidade dentro de um módulo, por exemplo, uma classe ou um método. alta coesão descreve um módulo que tem um propósito claro e não é mais complexo do que precisa ser. baixa coesão descreve um módulo que tem uma finalidade pouco clara ou que é excessivamente complexo.
- component - uma parte discreta que tem um papel ou função específica, chamada de responsabilidade. Do ponto de vista do design, um componente eventualmente será transformado em um objeto, função ou grupo de subcomponentes
- conceptual integrity - a consistência do software. Software com integridade conceitual parecerá programado por um desenvolvedor, mesmo que tenha sido programado por uma equipe
- concern - um termo geral, referindo-se a alguma ação ou papel que faz parte da solução do problema.
- control object - um objeto cuja função é gerenciar outros objetos ou controlar suas interações
- counterexamples - durante a verificação do modelo, os contra-exemplos são instâncias em que o sistema não se comportou como esperado
- coupling - descrevendo a complexidade das conexões entre os módulos. módulos fortemente acoplados são altamente dependentes uns dos outros e difíceis de reutilizar em outros contextos. Módulos fracamente acoplados são menos dependentes e mais fáceis de reutilizar.
- class responsibility collaborator CRC - significa colaborador de responsabilidade de classe: uma técnica para resumir e mapear objetos em um projeto orientado a objetos.
- deadlock - uma situação em que o sistema nunca pode continuar porque os subprocessos precisam de outros subprocessos para agir antes que possam continuar
- decomposition - quebrar uma entidade em partes que podem ser implementadas separadamente
- degree - quando se fala em acoplamento, grau é o número de conexões entre os dois módulos de interesse. Esta é uma dimensão de como esses módulos são acoplados.
- design - o processo de planejamento de uma solução de software, levando em consideração os requisitos e restrições. Dividido em design conceitual de nível superior e design técnico mais específico.
- design patterns - soluções estabelecidas para problemas comuns de codificação. Caracterizado por sua forma e função geral, e não por código específico
- ease - quando se fala em acoplamento, facilidade é como as conexões são óbvias entre os módulos. Esta é uma dimensão de como esses módulos são acoplados.
- encapsulation - agrupando atributos e comportamentos em um objeto, expondo recursos desse objeto a outros objetos conforme necessário e restringindo os recursos restantes
- entity - o papel ou comportamento que está sendo representado por um objeto ou processo de software
- flexibility - quando se fala em acoplamento, flexibilidade é a facilidade com que um módulo pode ser trocado por um módulo diferente. Esta é uma dimensão do acoplamento.
- getter - um método para obter o valor de uma variável de classe que não é acessível diretamente
- generalization - fatorando características comuns de classes ou funções que podem ser reutilizadas em outros lugares. Permite mais reutilização de código
- global variable - uma variável que é acessível por qualquer sub-rotina ou subcomponente
- flexibility - a capacidade de um projeto de se adaptar a mudanças ou ser adaptado a diferentes propósitos
- implementation - o processo de criação de um programa de trabalho a partir do projeto
- information hiding - projetar classes para que as informações que outras classes não precisam sejam ocultadas delas.
- inheritance - atributos ou comportamentos que as subclasses herdam de uma superclasse ou implementam por meio de uma interface
- instantiate - criar um objeto de uma classe
- interface inheritance - um método de herança em que se uma classe implementa uma interface, ela deve definir todos os métodos especificados na interface
- Liskov substitution principle - um princípio afirmando que uma superclasse deve poder ser substituída por sua subclasse sem alterar significativamente o comportamento
- local variable - uma variável acessível apenas a uma classe ou sub-rotina
- maintenance - modificar o software após a entrega para corrigir, melhorar ou alterar recursos
- maintainable - a capacidade do código ser alterado
- model - uma representação abstrata dos principais conceitos e relacionamentos que compõem uma solução de software
- model checking - uma verificação sistemática de todos os estados do sistema. Consiste em várias etapas: fase de modelagem, fase de execução e fase de análise
- module - termo geral para se referir a uma unidade de programação, como uma classe ou um método.
- namespace - um contêiner abstrato para um grupo de módulos relacionados, dado um identificador exclusivo.
- object-oriented modelling - modelagem de uma solução de software usando conceitos de linguagens orientadas a objetos, como Java. Caracterizado por representar conceitos-chave com objetos de software.
- override - uma subclasse pode ter um método que já está na superclasse, caso em que o método da subclasse será usado.
- package - um meio de organizar classes relacionadas no mesmo namespace.
- polymorphism - a capacidade de interagir com objetos de diferentes tipos da mesma maneira. Geralmente alcançado por meio de herança ou por meio de interfaces em Java
- programming paradigm - o estilo ou a maneira pela qual a programação atinge seus objetivos, que pode variar de acordo com a linguagem e o conjunto de ferramentas
- quality attributes - propriedades de um sistema de software que indicam sua qualidade
- requirements - os requisitos que o software será projetado para atender. Estes podem ser requisitos funcionais, como fornecer algum resultado, ou requisitos de negócios, como ser amigável ao usuário ou atender a restrições orçamentárias.
- responsibility - o propósito ou função de um componente do software
- reusable - a capacidade do código ser reutilizado em diferentes contextos
- rule of least astonishment - um princípio de design que dita que um componente deve se comportar como se espera que ele se comporte
- separation of concerns - um princípio que dita que diferentes preocupações devem estar em diferentes módulos
- service-oriented architecture - um tipo de arquitetura caracterizada por fornecer serviços a clientes externos. Os clientes não sabem como esses serviços são prestados.
- sequence diagram - um diagrama UML que mostra a sequência de ações que formam um processo
- setter - um método para definir o valor de uma variável de classe que não é diretamente acessível. Permite restringir os valores para os quais a variável pode ser definida
- software architecture - a estrutura de nível superior de um sistema de software; como vários componentes são organizados em um todo coerente e funcional
- state diagram - um diagrama UML que mostra os diferentes estados de um sistema
- tradeoff - uma decisão entre alternativas em que cada uma oferece benefícios e desvantagens
- Unified Modelling Language UML - uma linguagem de design visual que abrange muitos diagramas diferentes que descrevem o software de diferentes maneiras
- verification - confirmação que a solução de software atende aos requisitos
