Questões de Concurso Para sad-pe

Um mecanismo de abstração essencial à análise e ao projeto estruturados é a decomposição funcional, que visa basicamente derivar um conjunto de funções computacionais e(ou) manuais, as quais, quando compostas, realizam um sistema que satisfaz requisitos.

Os diagramas de estrutura e de dicionário de dados, comuns na análise estruturada, são usados, basicamente, para o refinamento de diagramas de fluxos de dados, detalhados durante o desenho estruturado.

Um diagrama de contexto, por apresentar várias bolhas conectadas entre si, por onde fluem dados, é considerado um diagrama de fluxo de dados

O diagrama de estrutura, técnica utilizada na análise e no projeto estruturados, difere, quanto à forma de organização, de um diagrama de fluxos de dados, principalmente em razão de sua ênfase no fluxo de dados, em detrimento da descrição dos fluxos de controle.

O desenvolvimento de diagramas entidade-relacionamento, nos métodos de análise e desenho estruturados, usualmente, precede o desenvolvimento de especificações de processos.

Os contratantes ou clientes são os principais colaboradores envolvidos no fornecimento de informações para o processo de levantamento ou elicitação de requisitos de software, os demais grupos de pessoas que podem fornecer informações são considerados de importância secundária.

As necessidades dos usuários a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restrições mencionadas na definição de requisitos constituem a classe de requisitos não funcionais.

Entre as fontes de informação para a elicitação de requisitos, destacam-se, além dos colaboradores, o conhecimento do domínio de aplicação em que o software funcionará, o ambiente operacional do software e o ambiente organizacional.

A negociação de requisitos, de forma similar à observação do ambiente organizacional, é uma atividade típica da fase de elicitação de requisitos.

A técnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, é mais aderente à construção de cenários durante a construção de protótipos que durante a elicitação de requisitos.

As atuais linguagens orientadas a objeto não são adequadas à implementação de algoritmos desenvolvidos para a programação estruturada, visto que muitos algoritmos estruturados não permitem o encapsulamento.

Na construção de tipos de dados estruturados, a declaração de classes não corresponde à definição de um novo tipo de dados estruturado.

Em linguagens orientadas a objeto, como Java, a declaração de quaisquer tipos de constantes é implementada por meio de macrossubstituição em linha, durante a pré-compilação, isto é, a substituição de referências a constantes pelo valor declarado.

Na linguagem Java, a avaliação de uma expressão que constrói uma nova instância, quando bem sucedida, retorna uma referência ou ponteiro à área de memória na qual a instância foi alocada.

A recursividade é técnica desnecessária caso a programação de um algoritmo seja efetuada em uma linguagem orientada a objetos, uma vez que o envio de uma mensagem a um objeto cria um contexto aninhado que corresponde, indiretamente, à técnica de recursão.

A modelagem de aspectos comportamentais de um programa orientado a objetos deve ser efetuada utilizando-se diagramas de classe e de instância, entre outros.

A modelagem de aspectos estruturais ou estáticos de programa orientado a objetos deve ser efetuada utilizando-se diagramas de comunicação, entre outros.

Na organização de um conjunto de especificações de sistemas orientados a objeto, package é elemento usado para se agregar, inclusive de forma hierárquica, um conjunto de outros elementos dentro de um mesmo espaço de nomes.

Na especificação da UML 2.0, destaca-se a existência da sublinguagem OCL (object constraint language), linguagem imperativa que, com variáveis e comandos de controle de fluxo, é usada para complementar diagramas UML.

Para um conjunto de ferramentas CASE que necessitam manter intercâmbio de modelos UML desenvolvidos entre si, o formato-padrão mais recomendado a ser utilizado é o UMLDoc, embasado na linguagem Java.

Os métodos clássicos de análise e de projeto orientado a objetos buscam refinar aplicação orientada a objetos, desde os requisitos até o código, empregando o conceito de desenvolvimento sem compartimentos, no qual as abstrações orientadas a objeto de nível mais elevado são transformadas em novo conjunto de abstrações que pouco preservam as relações com nível superior por meio da transição bem definida entre as fases do processo de desenvolvimento.

Um modelo orientado a objetos em nível de análise é, tipicamente, composto por grande número de classes inter-relacionadas, contendo cada uma delas um conjunto de variáveis de estado e métodos em sua interface.

Na modelagem orientada a objetos, a ênfase reside nos dados mantidos pelas abstrações do modelo, em oposição ao que ocorre nos métodos estruturados, cuja ênfase inicial recai sobre as funções realizadas pelas abstrações do modelo.

Aspectos como concorrência, distribuição e persistência são mais comumente trabalhados na fase de projeto orientado a objetos que na fase de análise.

Um conjunto de cartões adequadamente desenvolvidos por meio da técnica CRC (class-responsibilities-colaborators) constitui um artefato útil para um desenvolvedor iniciar o processo de codificação de um programa orientado a objetos, na linguagem de programação na qual tenha proficiência.