Questões de Concurso Público EMGEPRON 2021 para Analista de Sistemas (Desenvolvimento de Sistemas)

No contexto da Análise e Projeto de Sistemas e do processo de desenvolvimento de software, a UML reconhece três tipos mais importantes de relações, conceituadas a seguir.
I. São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes, podendo existir entre classes ou entre objetos. II. São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. Este tipo de relação entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe. III. São relacionamentos entre um elemento mais geral e um mais específico. O elemento mais específico herda as propriedades e métodos do elemento mais geral. Este tipo de relação é também conhecida como herança no modelo a objetos, existindo só entre as classes.
Os tipos descritos em l, ll e lll são, respectivamente:

Na implementação de bancos de dados relacionais, busca-se solucionar ou minimizar dois problemas, descritos a seguir.
I. Está associado à ocorrência de informações armazenadas em arquivos separados, com conteúdos diferentes. II. Está associado à existência das mesmas informações em aplicações diferentes, como por exemplo, em arquivos de material e de registros de projetos.
As descrições em I e em II referem- se, respectivamente, aos seguintes termos:

Ao iniciar o desenvolvimento de um novo sistema, um dos primeiros passos a ser executado é o estudo e levantamento dos requisitos necessários para a construção do produto final. A partir das informações obtidas, desenvolve-se um modelo conceitual que será utilizado para orientar o desenvolvimento propriamente dito, fornecendo informações sobre os aspectos relacionados ao domínio do projeto em questão. Esse modelo é baseado na percepção do mundo real, consistindo de um conjunto de objetos, elaborado para facilitar o projeto do banco de dados, possibilitando especificar a estrutura lógica geral do BD. A figura abaixo ilustra esse modelo conceitual, empregado na Engenharia de Software para descrever os objetos envolvidos em um domínio de negócios, com seus atributos e como eles se relacionam entre si.


Essa figura representa uma ferramenta conhecida por Modelo ou Diagrama:

Um processo de desenvolvimento de software pode ser visto como um conjunto de fases organizadas, usadas para definir, desenvolver, testar e manter um software. Existem diversos processos, cabendo destacar que há algumas fases básicas comuns à grande parte dos existentes. Em uma dessas fases, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código - executável para o desenvolvimento software. Em um processo de desenvolvimento orientado a objetos, essa etapa ocorre definindo as classes de objetos do sistema em questão, fazendo uso das linguagens de programação. Pode-se também utilizar ferramentas de software e bibliotecas de classes preexistentes para agilizar a atividade, como também o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias atividades, onde inclui-se geração de código-fonte e documentação.
Essa fase é denominada:

No desenvolvimento de software, o início para toda a atividade parte do levantamento de requisitos, sendo repetida em todas as demais etapas da engenharia de requisitos. Sommerville propõe um processo genérico de levantamento e análise que contém diversas atividades, sendo três delas detalhadas a seguir.
I. É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos, e a compreensão do domínio se desenvolve mais durante essa atividade. II. É um estágio que envolve interação com os stakeholders para a definição dos requisitos mais importantes, considerando que, em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. III. É o processo que realiza uma análise dos requisitos para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
As atividades detalhas em I, II e III são conhecidas, respectivamente, como: