Internet:<http://people.morehead-st.edu>.

A figura acima relaciona conceitos oriundos dos paradigmas de base de dados e de programação orientada a objetos.

Julgue o próximo item, considerando os elementos apresentados nessa figura.

SGBDs de código aberto, como o MySQL, suportam o armazenamento persistente de cadeias de bytes que foram geradas a partir de objetos Java que estavam alocados na memória heap, e que foram serializados usando-se algoritmos nativos da JVM. Para o armazenamento de objetos serializados em SGBD de código aberto, é indicado o uso de tipos de dados SQL BLOB ou outro tipo de dados de tamanho variável que armazene cadeias de caracteres binários.

Internet:<http://people.morehead-st.edu>.

A figura acima relaciona conceitos oriundos dos paradigmas de base de dados e de programação orientada a objetos.

Julgue o próximo item, considerando os elementos apresentados nessa figura.

As demandas de tratamento de integridade, concorrência e recuperação durante a implementação de SGBDs são maiores nos casos de banco de dados que fornecem suporte a transações, quando comparadas com aqueles que trabalham com bases de dados analíticas e com tecnologias de datawarehouse.

Kruchten. Architectural blueprints – the 4+1 view model of software architecture.

A figura acima apresenta o modelo denominado visão 4+1 utilizado para a descrição da arquitetura de sistemas de software. Na periferia dos quatro quadrantes do diagrama ilustrado, são apresentados exemplos de tópicos de discussão, conceitos e profissionais associados à construção de cada visão. No que se refere aos conceitos e informações apresentadas na figura acima e à sua relação com os elementos da estrutura e dos requisitos de software do SWEBOK, dos padrões GOF e do sistema POSA2, julgue o item subseqüente.

A visão física (physical view) está mais associada à disciplina de qualidade de software que à de gerência de configuração de software, ambas do documento SWEBOK.

Kruchten. Architectural blueprints – the 4+1 view model of software architecture.

A figura acima apresenta o modelo denominado visão 4+1 utilizado para a descrição da arquitetura de sistemas de software. Na periferia dos quatro quadrantes do diagrama ilustrado, são apresentados exemplos de tópicos de discussão, conceitos e profissionais associados à construção de cada visão. No que se refere aos conceitos e informações apresentadas na figura acima e à sua relação com os elementos da estrutura e dos requisitos de software do SWEBOK, dos padrões GOF e do sistema POSA2, julgue o item subseqüente.

Entre as disciplinas de processo de engenharia de software e de desenho de software do SWEBOK, a primeira está mais associada à visão de processo (process view).

Kruchten. Architectural blueprints – the 4+1 view model of software architecture.

A figura acima apresenta o modelo denominado visão 4+1 utilizado para a descrição da arquitetura de sistemas de software. Na periferia dos quatro quadrantes do diagrama ilustrado, são apresentados exemplos de tópicos de discussão, conceitos e profissionais associados à construção de cada visão. No que se refere aos conceitos e informações apresentadas na figura acima e à sua relação com os elementos da estrutura e dos requisitos de software do SWEBOK, dos padrões GOF e do sistema POSA2, julgue o item subseqüente.

Com relação ao SWEBOK, a visão de desenvolvimento (development view) está mais associada à disciplina de gerência de engenharia de software que à de qualidade de software.

Kruchten. Architectural blueprints – the 4+1 view model of software architecture.

A figura acima apresenta o modelo denominado visão 4+1 utilizado para a descrição da arquitetura de sistemas de software. Na periferia dos quatro quadrantes do diagrama ilustrado, são apresentados exemplos de tópicos de discussão, conceitos e profissionais associados à construção de cada visão. No que se refere aos conceitos e informações apresentadas na figura acima e à sua relação com os elementos da estrutura e dos requisitos de software do SWEBOK, dos padrões GOF e do sistema POSA2, julgue o item subseqüente.

A visão lógica (logical view) está mais associada à disciplina de requisitos de software que a de construção de software do documento SWEBOK.

Kruchten. Architectural blueprints – the 4+1 view model of software architecture.

A figura acima apresenta o modelo denominado visão 4+1 utilizado para a descrição da arquitetura de sistemas de software. Na periferia dos quatro quadrantes do diagrama ilustrado, são apresentados exemplos de tópicos de discussão, conceitos e profissionais associados à construção de cada visão. No que se refere aos conceitos e informações apresentadas na figura acima e à sua relação com os elementos da estrutura e dos requisitos de software do SWEBOK, dos padrões GOF e do sistema POSA2, julgue o item subseqüente.

As setas apresentadas no diagrama estabelecem uma ordenação temporal na construção das visões arquiteturais e, desse modo, o modelo de visão arquitetural 4+1, de uma forma geral, possui uma forte associação com as disciplinas de processo de engenharia de software e gerência de engenharia de software do SWEBOK, o que não ocorre com os sistemas de arquitetura estabelecidos no GOF e no POSA2 que por sua vez estão mais orientados para a disciplina de desenho de software do SWEBOK.

A figura acima, que foi adaptada do sítio http://www.cs.wustl.edu, apresenta um sistema de padrões de desenho conhecido como POSA2, constituído, entre outros, pelos elementos indicados por A, B, C e D e pelos padrões de desenho orientado a objeto nomeados nos retângulos mostrados. Com relação às informações apresentadas e aos conceitos de análise e projeto de software orientado a objetos, de arquitetura de software, de programação orientada a objetos e de padrões de projeto ou desenho, julgue o item que se segue.

Caso se deseje transmitir, por meio de invocação de procedimento remoto orientado a objeto, uma lista de parâmetros. O padrão acceptor-connector é mais indicado que o padrão serializer.

A figura acima, que foi adaptada do sítio http://www.cs.wustl.edu, apresenta um sistema de padrões de desenho conhecido como POSA2, constituído, entre outros, pelos elementos indicados por A, B, C e D e pelos padrões de desenho orientado a objeto nomeados nos retângulos mostrados. Com relação às informações apresentadas e aos conceitos de análise e projeto de software orientado a objetos, de arquitetura de software, de programação orientada a objetos e de padrões de projeto ou desenho, julgue o item que se segue.

Caso seja necessário prover acesso orientado a objetos a um conjunto de operações disponíveis em um sistema legado, entre os padrões adapter e wrapper facades, o uso do primeiro é mais adequado.

A figura acima, que foi adaptada do sítio http://www.cs.wustl.edu, apresenta um sistema de padrões de desenho conhecido como POSA2, constituído, entre outros, pelos elementos indicados por A, B, C e D e pelos padrões de desenho orientado a objeto nomeados nos retângulos mostrados. Com relação às informações apresentadas e aos conceitos de análise e projeto de software orientado a objetos, de arquitetura de software, de programação orientada a objetos e de padrões de projeto ou desenho, julgue o item que se segue.

Caso seja necessário adotar uma solução reusável para controlar o acesso concorrente a um componente de software, é mais indicado o uso do padrão broker, em comparação com o padrão monitor object.