Do ponto de vista do hardware e da programação, o que podemos dizer sobre o conceito “tipo de dados”?

Quando consideramos o hardware do computador, o termo “tipo de dados” pode ser utilizado para classificar o tipo de informação que está contida em uma determinada célula de memória (inteiro, float, string…), sendo que esse tipo de dado é nativo do computador, ou seja, nessa abordagem, o conceito “tipo de dados”, é totalmente acoplado à arquitetura de hardware utilizada e o chamamos de tipo de dado Primário ou Primitivo conforme exemplificado abaixo:

Tipo de dados em C

Porém o conceito “tipo de dados” pode ser analisado sob uma ótica completamente diferente, desacoplando o seu significado das limitações impostas pelo hardware de uma arquitetura e aproximando esse conceito da função que deve ser executada.

Ao abstrairmos da arquitetura de hardware o conceito de “tipo de dados”, exemplificando, em uma operação de soma de dois inteiros, deixa de ser necessário descer ao nível de hardware e bits a fim de se conhecer detalhadamente o mecanismo empregado pelo computador para obter o resultado dessa soma.

Nesse caso utilizamos o hardware do computador para representar os inteiros e representar a execução da operação de soma entre esses dois inteiros, repito, sem conhecer os detalhes da implementação em hardware dessa operação.

Dissociado o tipo de dado da limitação arquitetural de hardware do computador, abre-se a possibilidade de representarmos uma quantidade ilimitada de tipos de dados e esse é o pulo do gato (jump of the cat).

Considerando abstrato o conceito “tipo de dados”, o dissociando das limitações de hardware e o empregando para definir um conjunto de definições lógicas, podemos então implementar por software esse conjunto de definições lógicas, a partir de um conjunto limitado de instruções de hardware, transcendendo as limitações do mesmo.

Estipula-se um novo tipo de dado, define-se suas características, especifica-se as operações possíveis a serem executadas nesse objeto e procede-se com a implementação em software do mesmo, a exemplo dos tipos de dados utilizados em Big Data, alguns listados abaixo:

Tipos de dados utilizados em Big Data

Fonte: TENENBAUM, Aaron M.; LANGSAM, Yedidyah; AUGESNSTEIN, Moshe J.. Estruturas de Dados Usando C. São Paulo: Pearson, 2013. 884 p. ISBN 13: 978-85-346-0348-5.

Publicado em 2022/dez/14 por Renato de Pierri

Cuidados ao instalar o Maven no Windows

Se você instalou o Maven para Rodar com o Windows e está tentando usar o Oracle JDeveloper ou alguma outra IDE da Oracle e as coisas não estão funcionando muito bem, talvez seja a hora de ajustar algumas configurações no seu Windows.

  1. Baixe o Maven do site da Apache próprio para o Windows, descompacte e mova a pasta com o Maven para a pasta Arquivos de Programas ou para o diretório de sua escolha.
  2. Em propriedades do sistema do Windows, adicione a variável de ambiente M2_HOME com o valor do caminho do Maven
  3. Adicione a variável de ambiente M2 nas variáveis ​​de ambiente com o valor %M2_HOME%\bin
  4. Adicione a variável de ambiente MAVEN_OPTS com o valor -Xms256m -Xmx512m
  5. Adicione a variável de ambiente JAVA_HOME. Ela deve apontar para o diretório raiz do JDK (o diretório do JRE não serve para nada).
  6. Inclua %M2% na variável de ambiente Path
  7. Inclua %JAVA_HOME%\bin na variável de ambiente Path
  8. No prompt de comando execute mvn –version para verificar se o Maven instalou ok.

Para saber mais: JDeveloper / Maven integration

Post publicado em 21/11/2019 por Renato de Pierri

Qual é a diferença entre requisitos funcionais e requisitos não funcionais na engenharia de software?

Resposta originalmente publicada no Quora em 01/11/2019

Olha, dei uma lida no Sommerville e lá está escrito mais ou menos o seguinte:

Requisitos funcionais:

É a definição das funcionalidades que um sistema de software deve fornecer. Esse tipo de requisito informa como o sistema deve trabalhar os dados de entrada e quais informações devem ser geradas na saída.

Serve para definir o comportamento do sistema em situações específicas. Os requisitos funcionais também servem para definir o escopo do sistema de software ao limitarem explicitamente o que o sistema deve ou não deve fazer.

Requisitos não funcionais:

Esse tipo de requisito trata das limitações nos serviços ou funções oferecidas pelo sistema baseando em parâmetros como “número de transações por segundo”, “número de usuários operando o sistema ao mesmo tempo” ou limitações impostas por padronizações, por exemplo.

Requisitos não funcionais muitas vezes se aplicam à implementação e operação do sistema como um todo ao contrário de focar em funcionalidades e ou serviços individuais de sistemas.


Na verdade, há uma linha não muito clara entre o que é requisito funcional e não funcional. Dependendo da abordagem isso pode ficar confuso.

Um requisito de usuário de segurança como limitar o tempo de acesso de usuários autenticados, pode se enquadrar como requisito não funcional.

Entretanto quando visto com mais detalhes, o requisito de limitar o tempo de acesso de usuário pode se desdobrar em outros requisitos claramente funcionais.

Esse desdobramento pode levar o requisito da limitação do tempo de acesso a ser tratado como um requisito funcional.

Isso mostra que requisitos de um sistema de software são interligados e um requisito pode gerar limitações, influenciar ou mesmo acabar gerando outros requisitos.

Os requisitos de sistema entretanto não só especificam serviços ou funcionalidades do sistema.

Eles também especificam o que é necessário para assegurar que os serviços e funcionalidades sejam efetivamente entregues.

Fonte: SOMMERVILLE, Ian. Software Engineering: Tenth Edition. 10. ed. Boston: Pearson, 2016. 796 p. ISBAN 13: 978-0-13-394303-0. página 91

Como o levantamento de histórias e cenários podem ajudar na elucidação de requisitos para o desenvolvimento de um sistema de software?

Pergunta publicada originalmente no Quora em 01/11/2019

Aí galera, segue a minha visão sobre o assunto depois de dar uma lida no Sommerville.

Um dos objetivos do processo de elucidação de requisitos é conhecer o trabalho que os stakeholders (interessados no projeto) querem implementar no sistema, de forma a ajudá-los em suas atividades.

Durante a elucidação de requisitos, os engenheiros de software trabalham junto com os stakeholders para entender o domínio da aplicação.

Os engenheiros de software levantam as atividades trabalhadas, os serviços, as funcionalidades que precisam ser implementadas no sistema, bem com tomam conhecimento da performance desejada e assimilam as limitações impostas pelo hardware, dentre outros pontos.

Dado que pessoas, incluindo stakeholders, normalmente tem dificuldades em definirem requisitos de forma abstrata, muitas vezes eles são levantados a partir de exemplos da vida real, mais fáceis de serem obtidos.

Pessoas são capazes de descrever como enfrentam situações particulares ou são boas em descreverem como seria possível, a elas, melhorarem seus métodos de trabalho.

Levantamento de histórias e cenários é uma ferramenta poderosa para que engenheiros de software capturarem esse tipo de informação, normalmente descrita em linguagem natural.

De posse dessas histórias e cenários, o engenheiro de software os utiliza nas reuniões com os stakeholders para definir quais funcionalidades do software devem ser implementadas e ou deprecadas.

Para saber mais:

SOMMERVILLE, Ian. Software Engineering: Tenth Edition. 10. ed. Boston: Pearson, 2016. 796 p. ISBN 13: 978-0-13-394303-0. –

Tópicos:

  • Requirements elicitation
  • Stories and scenarios.

Last updated by at .