Questões de Concurso Público TRE-PE 2017 para Analista Judiciário - Análise de Sistemas
Foram encontradas 60 questões
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792277
Banco de Dados
Assinale a opção que corresponde ao tipo de restrição de
integridade expressa no próprio diagrama de entidades e
relacionamentos no modelo relacional.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792278
Engenharia de Software
A ISO barra I E C 9126 descreve uma das características
do modelo de qualidade de software como capacidade do produto
de software de apresentar desempenho apropriado, relativo
à quantidade de recursos usados, sob condições especificadas.
Essa característica corresponde à
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792279
Engenharia de Software
Com relação ao processo de contagem de pontos de função, assinale
a opção correspondente à etapa responsável por reconhecer a
complexidade e a contribuição de cada uma das funções contadas.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792280
Arquitetura de Software
A respeito de arquitetura orientada a serviços (S O A), assinale a
opção correta.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792281
Arquitetura de Software
Assinale a opção que apresenta o padrão de projeto que tem por
objetivo separar o display de estado de um objeto a partir do objeto
em si e que permite que sejam fornecidos displays alternativos.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792282
Programação
REST (representational state transfer) é
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792283
Arquitetura de Software
O E C M (enterprise content management) é
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792284
Engenharia de Software
O DDD (domain-driven design)
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792285
Modelagem de Processos de Negócio (BPM)
O B P M (business process management)
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792286
Programação
Acerca do clean code, assinale a opção correta.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792287
Segurança da Informação
Acerca de criptografia, assinale a opção correta.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792288
Engenharia de Software
Refactoring é o processo que
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792289
Engenharia de Software
O desenvolvimento orientado a testes (TDD)
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792290
Banco de Dados
Texto associado
Tabela 3A6AAA
dados da tabela:
ID; nome; idtipo; preco
25; creme; 3; 11,50
31; arroz; 4; 12,50
34; leite; 1; 14,00
42; sabão; 5; 11,00
46; carne; 1; 12,75
48; shampoo; 5; 12,30
58; azeite; 1; 13,25
Considerando-se os campos e dados contidos na tabela 3A6AAA,
denominada tbproduto, é correto afirmar que o comando SQL.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792291
Banco de Dados
Texto associado
Tabela 3A6AAA
dados da tabela:
ID; nome; idtipo; preco
25; creme; 3; 11,50
31; arroz; 4; 12,50
34; leite; 1; 14,00
42; sabão; 5; 11,00
46; carne; 1; 12,75
48; shampoo; 5; 12,30
58; azeite; 1; 13,25
Assinale a opção que apresenta o comando S Q L correto
para se incluir um novo campo idcategoria do tipo INT
nos dados da tabela 3A6AAA, denominada tbproduto.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792292
Programação
Assinale a opção que indica a descrição correta de um array
denominado empregados que contenha três objetos compostos
pelo registro do primeiro e do último nome de um empregado em
uma matriz J S O N.
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792293
Inglês
Texto associado
Text 3A7AAA
Software architecture is a complex topic. Due to its
complexity, our profession has produced a variety of definitions,
each more or less useful depending on your point of view. Here is
a definition from my first book, Journey of the Software
Professional: “A system architecture defines the basic “structure”
of the system (e.g., the high level modules comprising the major
functions of the system, the management and distribution of data,
the kind and style of its user interface, what platform(s) will it run
on and so forth)”.
This definition is pretty consistent with many others.
However, it lacks some important elements, such as specific
technology choices and the required capabilities of the desired
system. A colleague of mine, Myron Ahn, created the following
definition of software architecture. It is a bit more expansive and
covers a bit more ground than my original: “Software architecture
is the sum of the nontrivial modules, processes, and data of the
system, their structure and exact relationships to each other, how
they can be and are expected to be extended and modified, and on
which technologies they depend, from which one can deduce the
exact capabilities and flexibilities of the system, and from which
one can form a plan for the implementation or modification of the
system”.
We could extend these definitions from the technical point
of view, but this wouldn’t provide a lot of value. More than any
other aspect of the system, architecture deals with the “big picture”.
The real key to understanding it is to adopt this big picture.
Moreover, while these definitions are useful, they are far too
simplistic to take into account the full set of forces that shape, and
are shaped by, an architecture. In truth, I doubt that any single
definition of software architecture will ever capture all of what we
believe to be important.
Luke Hohmann. Defining software architecture. In: Beyond
software architecture: creating and sustaining winning
solutions. Boston: Addison-Wesley, 2003, p. 1-2 (adapted).
About the definition for software architecture, text 3A7AAA
shows that
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792294
Inglês
Texto associado
Text 3A7AAA
Software architecture is a complex topic. Due to its
complexity, our profession has produced a variety of definitions,
each more or less useful depending on your point of view. Here is
a definition from my first book, Journey of the Software
Professional: “A system architecture defines the basic “structure”
of the system (e.g., the high level modules comprising the major
functions of the system, the management and distribution of data,
the kind and style of its user interface, what platform(s) will it run
on and so forth)”.
This definition is pretty consistent with many others.
However, it lacks some important elements, such as specific
technology choices and the required capabilities of the desired
system. A colleague of mine, Myron Ahn, created the following
definition of software architecture. It is a bit more expansive and
covers a bit more ground than my original: “Software architecture
is the sum of the nontrivial modules, processes, and data of the
system, their structure and exact relationships to each other, how
they can be and are expected to be extended and modified, and on
which technologies they depend, from which one can deduce the
exact capabilities and flexibilities of the system, and from which
one can form a plan for the implementation or modification of the
system”.
We could extend these definitions from the technical point
of view, but this wouldn’t provide a lot of value. More than any
other aspect of the system, architecture deals with the “big picture”.
The real key to understanding it is to adopt this big picture.
Moreover, while these definitions are useful, they are far too
simplistic to take into account the full set of forces that shape, and
are shaped by, an architecture. In truth, I doubt that any single
definition of software architecture will ever capture all of what we
believe to be important.
Luke Hohmann. Defining software architecture. In: Beyond
software architecture: creating and sustaining winning
solutions. Boston: Addison-Wesley, 2003, p. 1-2 (adapted).
Both definitions presented in text 3A7AAA mention
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792295
Inglês
Texto associado
Text 3A7AAA
Software architecture is a complex topic. Due to its
complexity, our profession has produced a variety of definitions,
each more or less useful depending on your point of view. Here is
a definition from my first book, Journey of the Software
Professional: “A system architecture defines the basic “structure”
of the system (e.g., the high level modules comprising the major
functions of the system, the management and distribution of data,
the kind and style of its user interface, what platform(s) will it run
on and so forth)”.
This definition is pretty consistent with many others.
However, it lacks some important elements, such as specific
technology choices and the required capabilities of the desired
system. A colleague of mine, Myron Ahn, created the following
definition of software architecture. It is a bit more expansive and
covers a bit more ground than my original: “Software architecture
is the sum of the nontrivial modules, processes, and data of the
system, their structure and exact relationships to each other, how
they can be and are expected to be extended and modified, and on
which technologies they depend, from which one can deduce the
exact capabilities and flexibilities of the system, and from which
one can form a plan for the implementation or modification of the
system”.
We could extend these definitions from the technical point
of view, but this wouldn’t provide a lot of value. More than any
other aspect of the system, architecture deals with the “big picture”.
The real key to understanding it is to adopt this big picture.
Moreover, while these definitions are useful, they are far too
simplistic to take into account the full set of forces that shape, and
are shaped by, an architecture. In truth, I doubt that any single
definition of software architecture will ever capture all of what we
believe to be important.
Luke Hohmann. Defining software architecture. In: Beyond
software architecture: creating and sustaining winning
solutions. Boston: Addison-Wesley, 2003, p. 1-2 (adapted).
The author of text 3A7AAA concludes that
Ano: 2017
Banca:
CESPE / CEBRASPE
Órgão:
TRE-PE
Prova:
CESPE - 2017 - TRE-PE - Analista Judiciário - Análise de Sistemas |
Q792296
Inglês
Texto associado
Text 3A7AAA
Software architecture is a complex topic. Due to its
complexity, our profession has produced a variety of definitions,
each more or less useful depending on your point of view. Here is
a definition from my first book, Journey of the Software
Professional: “A system architecture defines the basic “structure”
of the system (e.g., the high level modules comprising the major
functions of the system, the management and distribution of data,
the kind and style of its user interface, what platform(s) will it run
on and so forth)”.
This definition is pretty consistent with many others.
However, it lacks some important elements, such as specific
technology choices and the required capabilities of the desired
system. A colleague of mine, Myron Ahn, created the following
definition of software architecture. It is a bit more expansive and
covers a bit more ground than my original: “Software architecture
is the sum of the nontrivial modules, processes, and data of the
system, their structure and exact relationships to each other, how
they can be and are expected to be extended and modified, and on
which technologies they depend, from which one can deduce the
exact capabilities and flexibilities of the system, and from which
one can form a plan for the implementation or modification of the
system”.
We could extend these definitions from the technical point
of view, but this wouldn’t provide a lot of value. More than any
other aspect of the system, architecture deals with the “big picture”.
The real key to understanding it is to adopt this big picture.
Moreover, while these definitions are useful, they are far too
simplistic to take into account the full set of forces that shape, and
are shaped by, an architecture. In truth, I doubt that any single
definition of software architecture will ever capture all of what we
believe to be important.
Luke Hohmann. Defining software architecture. In: Beyond
software architecture: creating and sustaining winning
solutions. Boston: Addison-Wesley, 2003, p. 1-2 (adapted).
In the first line of text 3A7AAA, the expression “Due to” could
be correctly replaced by
Conheça nossos planos