Um dos objetivos da BPMN é criar um mecanismo simples para o desenvolvimento dos modelos de processos de negócio e, ao mesmo tempo, poder garantir a complexidade inerente aos processos. A simbologia adotada está dividida em quatro categorias básicas de elementos, ou seja,

Preenchem correta e respectivamente as lacunas I, II e III acima:

Enterprise Service Bus − ESB:

Em relação à componentização e reuso, considere:

I. Se o componente sendo projetado é muito complicado, então, não é usável, por ser muito complexo ou apenas uma pequena porção desse componente é usada. Ao projetar um componente reusável, deve-se estar atento para que ele seja tão simples quanto possível.

II. Quando é projetada uma solução baseada em componentes, é possível obter um comportamento comum de modo que vários usuários possam utilizar. Uma outra forma para reuso de interfaces genéricas é o reuso da especificação. Uma vez que os componentes podem possuir múltiplas interfaces, é possível ter diferentes componentes.

III. No que concerne ao reuso dos componentes existentes, as interfaces podem ser projetadas para usar outras interfaces em tempo de design (desde que todas as implementações de componentes no sistema especificado suportem as interfaces) ou em tempo de implementação (usa os serviços de outras interfaces).

É correto o que consta em

Requisitos não funcionais são aqueles que declaram restrições ou atributos de qualidade para um software e/ou para o processo de desenvolvimento de um sistema. Algumas classificações dos requisitos não funcionais podem ser encontradas na literatura, tais como, as propostas por Mamani [Mamani 99] e por Sommerville [Sommerville 92], apresentadas abaixo.

A correta correspondência entre os autores e suas respectivas proposições é

Representar a arquitetura de software em várias visões, utilizando vários modelos, produz um resultado mais consistente uma vez que há muita informação dissociada para retratar em um único modelo. Nesse sentido considere os itens abaixo, relativos aos principais esquemas de visões:

I. Um esquema que ressalta, em separado, os detalhes estático, dinâmico e funcional dos objetos identificados no sistema, ou seja, cada objeto possui sua estrutura e sua descrição definidas do ponto de vista estático, dinâmico e funcional.

II. As visões determinam uma seqüência de atividades que ocorrem no tempo, ou seja, uma evolução incremental dos conceitos do negócio e suas representações. Primeiro devem ser pensados os detalhes da visão lógica para, em seguida, se pensar nos detalhes da visão física. As semânticas determinam as representações estática e dinâmica de ambas as visões.

III. Um esquema onde as visões são coordenadas com o objetivo de representar a arquitetura como um modelo de abstração que possui o foco na estrutura nos elementos essenciais, sugerindo a notação UML [Booch98] como principal mecanismo de representação dos propósitos das visões.

IV. Um esquema onde vários propósitos são atendidos pelas visões, tais como, abordar a organização lógica do sistema, organizar suas funcionalidades, abordar os aspectos de concorrência e descrever a distribuição física do software na plataforma utilizada. As visões se dividem em lógica, de processo, de desenvolvimento, de implementação e de casos de uso.

Os itens acima referem-se, respectivamente, às visões

No grafo exibido, o caminho v₁, v₂, v₄, v₃ tem comprimento igual a

O grafo representado é um grafo

A responsabilidade do kernel consiste, tradicionalmente, em abstrair a interface do hardware, permitindo que processos utilizem este recurso concorrentemente, de forma segura e padronizada. Assim, um kernel ou núcleo pode ser considerado o próprio sistema operacional, quando este é definido como um gerenciador de recursos de hardware, que é o caso do sistema operacional aberto Linux. O Linux é um

Nos sistemas multimídia,