Arquitetura de Sistemas

Prévia do material em texto

Arquitetura de Sistemas
Aula 1 - Componentes de Sistemas.
O conceito principal do uso de componentes está relacionado ao ditado “dividir para conquistar”. Isso significa gerenciar a complexidade, quebrando um grande problema em pedaços menores a serem desenvolvidos. Na sequência, integram-se esses pequenos módulos simples para resolver problemas complexos. Componentes seguem essa definição para sua construção, com a diferença que está relacionada a objetos de negócio, dados, interfaces que combinadas resolvem os problemas apresentados. Quando resolvemos criar um sistema de informação, utilizando a abordagem de componentes, será necessário primeiro mapear esses componentes em modelos conceituais, depois construi-los separadamente e, somente ao final, integrá-los para a solução do problema.
OBJETIVOS
Identificar os fundamentos e objetivos de um componente; Analisar um exemplo de componente e definir o que não é um componente; Distinguir arquitetura de sistemas e componentes; Definir especificação de componentes, implementação de componentes e níveis de modelo.
FUNDAMENTOS DE COMPONENTES
Componentes, no contexto da arquitetura de sistemas, são unidades de software estruturadas de acordo com alguns princípios específicos. Os princípios fundamentais que regem os componentes estão relacionados ao conceito de objetos, conforme descrito a seguir:
União de dados e funções Um objeto de software consiste em dados que podem assumir valores e funções que tratam esses dados. Os dados e funções devem ter uma ligação natural entre eles, formando o conceito de classe.
Encapsulamento Conceito de esconder de quem vai usar a classe os detalhes de sua funcionalidade e de dados, deixando amostra somente como acionar e o resultado a ser alcançado pelo acionamento. Não importam para quem vai usar tal componente, como as coisas acontecem dentro dele, e, sim, se o resultado esperado foi alcançado.
Fonte da Imagem: Identidade Cada componente encapsulado tem uma identidade única de dados e funções e pode assumir estado pré- determinados. O que é um componente afinal?
E UM OBJETO DERIVADO (INSTANCIADO) DE UMA CLASSE COM UMA ASSINATURA EXPLICITA CHAMDA DE INTERFACE.
ARQUITETURA DE SISTEMAS BASEADA EM COMPONENTE.
A arquitetura de sistemas baseada em componentes, então, está relacionada à identificação das interfaces possíveis e disponíveis e como elas resolvem os problemas que se apresentam. Esse conceito facilita muito o desenvolvimento e reduz o nível de mudança nos sistemas gerados.
Objetivos de componentes A partir de um objeto simples estruturado (componente) é necessário combinar funcionalidade e dados para resolver os problemas em sistemas computacionais. A grande decisão na abordagem por componentes na arquitetura de sistemas está em conseguirmos identificar claramente as interfaces e como elas resolvem os problemas que se apresentam. Isso está relacionado às dependências entre componentes. Pode até ser uma surpresa para alguns que, quando definem seus objetos, estão pensando somente na reutilização e não em como suas interfaces se relacionam em contextos variados. 
CARACTERÍSTICAS DE COMPONENTES 
Existem vários conceitos que podem definir os objetivos de um componente, todos com real validade, mas podemos armar que um componente contém as características necessárias para resolver problemas de forma natural e relacionado ao mundo.
EXEMPLO DE USO DE COMPONENTES 
Imagine que nosso sistema deve gerar um relatório em uma planilha eletrônica para que o usuário tenha como trabalhar com as informações e montar seus relatórios e gráficos personalizados. É bem razoável que não esteja no escopo do desenvolvimento do sistema a construção de um sistema de planilha eletrônica. É muito mais simples e eficaz utilizarmos o Excel ou a Planilha do OpenOce para este
Para que isso ocorra, precisamos mapear as interfaces de uso dessas planilhas e que elas sejam repassadas aos desenvolvedores dos novos componentes de maneira que se liguem ao componente “Planilha Eletrônica que se deseja utilizar”.
O que não é um componente? O fato de termos uma classe ou uma função escrita em uma linguagem de programação, compilada e instalada em nosso ambiente, por si só não atribui a esse código a funcionalidade de um componente de software. É necessário que tenhamos uma interface bem definida e que padrões de interação sejam suportados pelo componente. Somente neste caso ele estará apto a ser utilizado e classificado como componente. 
DEFINIÇÃO DE ARQUITETURA DE SISTEMAS E COMPONES
ARQUITETURAS DE SISTEMAS 
Podemos ter N camadas de arquiteturas distribuídas, ligando bancos de dados corporativos, pacotes de automação e sistemas em funcionamento na corporação, interagindo especificamente através dos aplicativos de processos de negócios software com as interfaces de usuário baseadas na web.
Camada da arquitetura de sistemas Quer usar componentes para-nos diferentes e para resolver preocupações diferentes. Nossa abordagem global é identificar as camadas diferentes nas quais os componentes podem ser utilizados. Isso é útil porque nos permite raciocinar sobre a finalidade de cada unidade de software que usaremos em nosso sistema. 
ARQUITETURA DE COMPONENTES 
Componentes podem ser encontrados em qualquer uma das camadas da Arquitetura de sistemas, conforme imagem anterior. Porém, o que nos interessa nesta aula são os componentes presentes nas camadas de sistemas e de negócio. Como vimos, a arquitetura de componentes é um conjunto elementos de software no nível de aplicativo que contém comportamentos e dependências em suas relações estruturais. Essa é uma definição independente do nível de tecnologia em que será implantado. A arquitetura de componentes pode ser usada em uma única aplicação ou para um contexto mais amplo, como um conjunto de aplicações que servem uma área de processo de negócio em particular. Dentro desse contexto, os componentes nos permitem entender como, dependendo do nível de integração (forte, moderada ou fraca), nosso sistema vai reagir às modificações e/ou à substituição de componentes.
Relação entre especificação de componentes e interfaces 
A especificação componente define a assinatura do componente e, consequentemente, a forma como será coutilizado e testado. Essa especificação define as formas de uso e delimita sua fronteira de acesso. Já a interface define a relação com os outros componentes, informando o que esperar quando se conectar a este componente. 
NÍVEIS DE MODELO 
Um modelo de algo apresenta uma perspectiva ou visão resumida do que é e do que aquilo permite. Deve claro que sempre em um modelo algumas coisas serão enfatizadas e outras serão excluídas.
Aula 2 - O processo de desenvolvimento
WORKFLOW 
Workow representa a metodologia (glossário) de desenvolvimento de sistemas baseada na metodologia RUP.
Parte-se da ideia do sistema, em seguida efetua-se a coleta de requisitos que, depois de validados, são encaminhados para a análise. Depois que os modelos conceituais de negócio são desenvolvidos, o processo é encaminhado para a especificação das funcionalidades e interfaces de sistemas. Ao final desse processo, as especificações são encaminhadas para codificação pela equipe de desenvolvimento, para, em seguida, serem efetuados os testes integrados e por último a implantação do novo sistema.
O GERENCIAMENTO DE PROCESSOS 
Refere-se ao conjunto de conhecimentos que serão utilizados para guiar a condução do projeto de desenvolvimento de software. Esses conjuntos de processos garantem que o resultado dos projetos será um sucesso, baseado nos grupos de processos que contém ações, distribuídas em 10 áreas do conhecimento da Gestão de Projetos, segundo o PMI®: Iniciação; Planejamento; Execução; Monitoramento e Controle; Encerramento da Gestão (glossário). Cada um dos grupos de processos se integra às áreas de conhecimento em uma sequência lógica que, quando seguida, viabiliza a execução do desenvolvimento com muito mais assertividade
DIFERENÇAS ENTRE MÉTODOS 
Em algunsmétodos de desenvolvimento, prega-se que os requisitos devam ser levantados até ser alcançada sua totalidade, independentemente do tempo que isso demore, com o objetivo de reduzir mudanças futuras. Outros métodos pregam que os requisitos mínimos devam ser levantados para iniciar ondas de desenvolvimento, e, com o passar do tempo, chegam a situação ideal sem perder muito tempo com requisitos. A justificativa seria: já que os requisitos vão mudar mesmo, então não se deve perder tempo com isso.
Fica claro que vão existir trabalhos de gestão e trabalhos de desenvolvimento. Os dois tipos de trabalhos vão coexistir em workows diferentes, que interagem e se integram para gerar um sistema muito mais assertivo do ponto de vista de funcionalidade e em conformidade com escopo, tempo, custo, riscos e qualidade. 
OBJETIVOS DA METODOLOGIA DE DESENVOLVIMENTO 
A metodologia de desenvolvimento tem como objetivo guiar o processo de produção de software, de forma que os componentes gerados tenham alta qualidade e sejam produzidos mais rapidamente, garantindo sua efetividade.
OBJETIVOS DA METODOLOGIA DE GESTÃO 
A metodologia de gestão deve contemplar quantas fases forem necessárias para conseguir que todas as áreas de conhecimento sejam abordadas de forma a garantir que escopo, tempo, custos e qualidade atinjam os níveis definidos pelas corporações como sendo os ideais. As fases da metodologia devem seguir um modelo (glossário) interativo e incremental. Nele, cada fase é dividida em uma ou mais iterações que visam uma entrega ao final. Veja a segui um exemplo das fases de um processo de desenvolvimento, testes e manutenções dos softwares. 
INTERAÇÃO ENTRE COMPONENTES 
A interação de componentes define como cada uma das operações do sistema será alcançada, utilizando a arquitetura de componentes. Usa-se a interação entre os modelos para descobrir as operações nas interfaces de negócios. Quanto mais interações são consideradas, operações e padrões de uso comuns são conseguidos e passam a poder ser reutilizados. Dessa maneira, as escolhas e possibilidades se tornam mais claras e as operações são movidas de uma interface para outra, quando necessárias.
Grupos alternativos de interface para os componentes podem ser utilizados e este é o momento de pensar as integrações referenciais entre componentes para que os problemas sejam minimizados e a integridade seja respeitada. Assim, a interação de componentes é o momento em que todos os fatores do sistema são levantados, com uma clara compreensão das dependências entre eles, chegando-se até o nível mais detalhado de operações.
 
ESPECIFICAÇÃO DE COMPONENTES 
É na fase final da especificação que ocorre o detalhamento das operações e as suas restrições. Para uma dada interface, devem-se definir os potenciais estados dos componentes e suas assinaturas e, em seguida, especificar as condições prévias e posteriores para as operações. Aqui são levantadas ainda as regras de negócios e restrições. As condições prévias e posteriores e outras restrições fazem referência aos tipos das informações de modelo de interface que, em conjunto com os tipos dos parâmetros, formam a assinatura da interface. A arquitetura não deve ser efetivamente alterada nesta fase. Essa tarefa de especificação detalhada somente deve ser realizada quando a definição da arquitetura estiver estável e todas as operações das interfaces forem identificadas. O ato de escrever as regras detalhadas para cada operação pode ajudar você a descobrir parâmetros que estejam faltando ou informações que precisem ser complementadas, mas a ênfase está em identificar cada detalhe em uma arquitetura estável.
01 - Quais são as três características de um projeto de desenvolvimento de software? 
Contínuo, Mensurável e Realizável.
Temporário, Mensurável e Realizável.
Temporário, Gera um resultado único e Elaborado Progressivamente. 
Gera um resultado único, Mensurável e Realizável.
JUSTIFICATIVA
II. Qual das respostas abaixo melhor define o conceito de ciclo de vida de projeto de desenvolvimento de software? 
As partes do projeto. 
Iniciação, planejamento, execução, monitoramento e controle e encerramento. 
As etapas que compõe o desenvolvimento de um projeto. 
As operações de um projeto.
JUSTIFICATIVA
III. O processo de decomposição para definição do escopo de um projeto de desenvolvimento de software é uma técnica utilizada para construir um(a): 
Diagrama de rede de precedência 
Método de diagrama de caminho crítico 
Estrutura Analítica do Projeto (EAP) 
Análise de variação.
Aula 3 - Aplicando UML
PORQUE PRECISAMOS DE UML NA ARQUITETURA DE SISTEMAS?
UML foi concebida para modelagem de projeto de sistemas orientado a objetos. Esse conceito tem uma relação direta com o desenvolvimento orientado a componentes, do conceito de arquitetura de sistemas.
Neste contexto, um dos itens que usaremos em nossa disciplina é a modelagem de pacotes de interface, em que os componentes são modelados sem a preocupação com a codificação, mas, sim, com a junção dos elementos do sistema para definir sua lógica de funcionamento. Veremos nesta aula que UML pode nos ajudar a definir e projetar a arquitetura do sistema, servindo como ferramenta de suporte à técnica de modelagem por componentes da arquitetura de sistemas. Não vamos aqui definir ou indicar uma ferramenta de modelagem UML específica, já que todas as ferramentas que se propõe a isso atendem aos objetivos propostos nesta disciplina.
TÉCNICAS DE MODELAGEM UML 
Os diagramas que vamos utilizar usam os mesmos nomes da UML, mas são aqui apresentados com uma funcionalidade específica. Temos também as seguintes variações: Veremos mais detalhadamente cada um deles nos próximos elementos desta aula. 
MODELO CONCEITUAL DE NEGÓCIO 
O modelo conceitual de negócio não é um modelo de software, mas sim um modelo de informação que define o domínio do problema. Sua principal finalidade é identificar e definir as relações existentes dentro do negócio. Usaremos o diagrama de classe UML para representá-lo, mas é importante claro que a ferramenta é independente do modelo, ou seja, poderemos generalizar cada classe do modelo e amarrá-las do ponto de vista de restrições. Depois, quando formos definir os pacotes, poderemos separar o negócio do sistema.
Os modelos conceituais de negócio, normalmente, definem classes conceituais e suas associações e, como previsto nesse modelo, as associações terão suas multiplicidades. O modelo pode conter atributos, caso isso seja significativo para explicar o negócio, mas seu uso não é obrigatório. A ênfase desse modelo é definir o domínio e não normalizar suas relações. 
MODELO CONCEITUAL DE SISTEMAS 
Diagrama de casos de uso O diagrama de casos de uso é modelo que define a funcionalidade do sistema a ser desenvolvido e contém os seguintes elementos.
Relação entre objetos 
Quando estamos falando da relação entre objetos, temos o include, que informa que o objeto A é parte do objeto B, caso exista entre eles uma relação do tipo include partindo de A. 
Outro tipo de relação entre objetos é o extends. Esse tipo de relação representa que o objeto D é uma extensão do objeto A, compartilhando suas funcionalidades e implementando algumas novas, que existem somente para ele.
Descrição de casos de uso 
Descrevem, geralmente na forma textual, as funcionalidades existentes no diagrama de casos de uso, no que diz respeito a como seus atores interagem com os objetos do sistema. Descrevem também como os objetos se relacionam entre si e, por último, a funcionalidade dos objetos.
DIAGRAMA DE DOMÍNIO 
O diagrama de domínio é uma variação do diagrama de classes e utiliza quase a mesma notação. Representa o domínio de dados a serem tratados e armazenados pelo sistema, ou seja, os elementos DAO do sistema. Garante uma visão sistêmica entre os componentes de interface e os componentes dedados do sistema.
ESPECIFICAÇÃO DE INTERFACE
A especificação de interfaces de componentes é a forma de descrever como os elementos quequiserem utilizar esses componentes: Devem acessá-lo (sua assinatura, com os parâmetros e retornos oferecidos); Quais os atributos que ele manipula; Quais as funções disponíveis para uso. Os componentes podem ser agrupados em pacotes, que reúnem componentes com funcionalidades e atributos complementares, dentro do conceito de família de componentes. Esses pacotes vão apresentar as informações necessárias para que possam ser utilizados no conceito de arquitetura de componentes, através de suas funcionalidades e operações.
ATIVIDADE PROPOSTA
Os modelos conceituais utilizados na UML garantem que os elementos de negócio, referentes ao sistema que está sendo desenvolvido, sejam completamente mapeados. Garantem também que haja uma migração consistente dos modelos conceituais de negócio para os modelos conceituais de sistemas. Dessa maneira, conseguimos que nossos sistemas atendam a seus objetivos e sejam desenvolvidos, segundo o melhor conjunto de boas práticas. Você acha que podemos fazer um paralelo entre esse conceito e a construção de um equipamento, atendendo às normas da ABNT e definições do INMETRO?
Questão 1:
 UML é uma linguagem de modelagem de uso geral que pode ser usada com os principais métodos de objetos e de componentes, podendo ainda ser aplicada a todos os domínios de aplicação e plataformas de implementação; Um relacionamento estendido entre casos de uso significa que o caso de uso base incorpora implicitamente, sob alguma condição, o comportamento de outro caso de uso. Um relacionamento de inclusão entre casos de uso significa que o caso de uso base incorpora explicitamente o comportamento de outro caso de uso. Relacionamentos de inclusão e extensão são representados pela mesma notação do relacionamento de dependência, com a seta apontada para o caso de uso base.
A alternativa completamente CORRETA é: 
A) I – II - III 
B) I – III – IV ,
C) II – III – IV 
D) I – III – IV 
E) I – II – III –IV
Questão 2: 
Diagramas de casos de uso são compostos por atores, casos de uso e seus relacionamentos; Diagramas de classes são compostos por classes e seus relacionamentos; Diagramas de sequência são compostos por objetos e suas trocas de mensagens, ou seja, chamadas de métodos para outros objetos; Considerando as sentenças acima, marque a opção correta: 
A) Somente as armativas I e III são verdadeiras. 
B) Somente as armativas II e III são verdadeiras. 
C) Somente as armativas I e II são verdadeiras. 
D) As armativas I, II e III são verdadeiras. 
E) Somente a alternativa I é verdade.
Questão 3: 
O diagrama UML, que apresenta um conjunto de objetos envolvidos em um cenário e a especificação das mensagens trocadas entre esses objetos ao longo de uma linha de tempo, é chamado de: 
A) Diagrama de mensagens 
B) Diagrama de sequência 
C) Diagrama de execução em linha de tempo 
D) Diagrama de estado 
E) Nenhuma das respostas anteriores
Questão 4: 
Em UML, são exemplos de diagramas responsáveis por representar o aspecto estrutural de um software: 
A) Diagrama de classes e diagrama de pacotes 
B) Diagrama de entidade relacionamento e diagrama de pacotes 
C) Diagramas de classes, diagrama de pacotes e use case.
D) Use case e diagrama de classes 
E) Nenhuma das respostas anterior
Questão 5: 
A atividade de análise de requisitos procura descobrir o que os stakeholders de um projeto de sistema de software querem que o sistema faça. Para ajudar na comunicação com os usuários e clientes vários diagramas da UML podem ser utilizados. Com relação à utilização dos diagramas da UML na atividade de análise de requisitos, analise se as sentenças a seguir são faltas ou verdadeiras e depois assinale a opção correta: 
( ) Diagrama de classes desenhado a partir da perspectiva conceitual é uma boa maneira de construir um vocabulário rigoroso do domínio. 
( ) Um diagrama de atividades é recomendo para exibir o fluxo de trabalho da organização, mostrando como o software e as atividades humanas interagem. 
( ) Um diagrama de objetos é indicado para representar um conceito que tenha um ciclo de vida com vários estados e os eventos que mudam esses estados. 
A) F, V e F 
B) F, V e V 
C) V, F e F 
D) V, V e F 
E) F, F e V
Questão 6: 
A UML é uma famosa linguagem usada para análise e projeto orientado a objetos. O seu diagrama de sequência tem como características, EXCETO: 
A) Geralmente é construído a partir dos Casos de Uso. 
B) Usado para representar interações entre objetos de um cenário, realizadas através de operações ou métodos. 
C) Dá ênfase ao fluxo de controle de uma atividade para outra. 
D) Dá ênfase à ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. 
E) Pode ser facilmente transformado em um Diagrama de Colabora
Aula 4 - Definição de Requisito
Podemos definir requisitos como condição ou exigência indispensável para um m, uma ocupação e/ou uma realização. Para começarmos é importante definirmos como as metodologias tratam requisitos e como essa disciplina fará a abordagem do tema, quais as diferenças encontradas no processo de levantamento de requisitos, no esforço gasto e em seus resultados, além de tratar da importância de requisitos para o resultado final do sist.
Diferenças no levantamento dos requisitos: Essa definição de esforço e dos mecanismos verá mais detalhadamente nos itens a seguir
REQUISITOS DE SISTEMAS
Os requisitos de sistemas fazem parte da família de requisitos e compartilham sua definição básica. Porém, estão associados a funcionalidades e tipos que veremos mais detalhadamente ainda nesta aula. O conhecimento adquirido aqui servirá para que nossas partes interessadas e nossas equipes de desenvolvimento não enfrentem o problema apresentado no quadro
ESFORÇO MÁXIMO E RESULTADOS ESPERADOS NA ETAPA DE REQUISITOS
TIPOS DE REQUISITOS
Registros 
FUNCIONAIS – EXPLICITOS, IMPLICITO.
NÃO FUNCIONAIS – EXPLICITO IMPLICITO.
FRAMEWORK DE CONHECIMENTOS EM TI COMO BASE PARA REQUISITOS
O framework de conhecimentos em TI tratado aqui se refere aos conhecimentos que vão além dos requisitos, como, por exemplo:
INFRAESTRUTURA DE HARDWARE
BANCO DE DADOS
COMUNICAÇÃO
CONFIABILIDADE DO SISTEMA
NIVEL DE CRITICIDADE DAS OPERAÇOES
DESEMPENHO DO SISTEMA
ADEQUAÇOES LEGAIS E ETICAS
SEGURANÇA
REUNIÃO DE LEVANTAMENTO DE REQUISITOS
Os trabalhos de levantamento e validação de requisitos deve conter uma reunião de levantamento de requisitos, com as seguintes características:
VALIDAÇÃO DE REQUISITOS
A validação de requisitos deve ser feita em duas etapas, chamadas de pré-validação e validação de requisitos.
Ao final desses passos, você terá seus requisitos validados por todas as partes interessadas no projeto. Além disso, conseguirá o apoio e o patrocínio necessário, pois todos são responsáveis pelo documento gerado e não somente a equipe de desenvolvimento.
MAS O QUE É UM CONCEITO DE MODELO CONCEITUAL FORTE?
A melhor maneira de responder isso é fazer um comparativo entre modelos conceituais de outras áreas de conhecimento que tenha modelos conceituais fortes, como os modelos conceituais de negócio e de sistemas. A partir dessa comparação, mais fácil entender o conceito proposto. Por exemplo, se usarmos como base para exemplificar um modelo conceitual forte pode partir da arquitetura e de uma planta de casa.
Não precisamos ser arquitetos para conseguir entender o conceito proposto a partir da planta (modelo). Isso representa a definição de um modelo conceitual forte
E O MODELO CONCEITUAL 
Quando olhamos para os diagramas de casos de uso, ou de classes, de objetos ou de componentes, verificamos que é necessário ser iniciado na arquitetura de sistemas para entender e validar se estão em conformidade com as necessidades do sistema a ser desenvolvidos (requisitos).
Isso representa um modelo conceitual fraco, ou seja, precisa de explicação externa para ser entendido. 
COMO CRIAR PARA A TI UM MODELO CONCEITUAL FORTE?
Como, então, criar para área de TI um modelo conceitual forte, que sejafacilmente entendido pelas partes interessadas e, ao mesmo tempo, esteja em adequação às boas práticas da arquitetura de sistemas? A resposta está na prototipação de sistemas! É com o protótipo que as partes interessadas vão conseguir facilmente verificar se seus requisitos estão presentes na definição do que será feito. 
MODELAGEM CONCEITUAL DE NEGÓCIOS E DE SISTEMAS A PARTIR DOS REQUISITOS VALIDA
S Agora que temos todos os requisitos levantados e validados de forma consistente e confiável pelas partes interessadas, podemos iniciar os trabalhos de modelagem conceitual de negócios e de sistemas. Essa modelagem será feita de acordo com os elementos estudados na aula.
RESULTADOS ESPERADOS
Como resultado final desse conjunto de processos, espera-se que todas as necessidades das partes interessadas estejam presentes nos sistemas desenvolvidos, na forma de funcionalidades, restrições e uso de tecnologias, atendendo plenamente a tudo o que se espera do novo sistema. É de responsabilidade da equipe de desenvolvimento o atingimento dos resultados esperados.
1. A gestão de requisitos é uma etapa importante do projeto por ser um conjunto de atividades que tem como principal objetivo ajudar a equipe de projeto a: 
A) Utilizar ferramentas de engenharia de software para modelar os requisitos do sistema, através da UML. 
B) Identificar, controlar e rastrear requisitos e modificações de requisitos em qualquer época, à medida que o projeto prossegue. 
C) Construir um modelo técnico refinado de funções, características e restrições do software. 
D) Negociar com os clientes os conflitos de prioridade de requisitos e identificar e analisar os riscos associados a cada requisito. 
E) Avaliar os requisitos quanto à qualidade, garantindo que ambiguidades, inconsistências, omissões e erros tenham sido detectados e corrigidos.
2. Os requisitos não funcionais normalmente surgem por meio das necessidades dos usuários, podem ser restrições de orçamento, políticas organizacionais ou mesmo por fatores externos, como regulamentos de segurança e legislações de privacidade. Juntamente com a classificação dos requisitos não funcionais estão os requisitos de produto, os quais: 
A) Especificam ou restringem o comportamento do software, incluindo requisitos de desempenho, especificações de rapidez de execução e requisitos de confiabilidade que estabelecem, por exemplo, a taxa aceitável de falhas. 
B) São os requisitos gerais de sistemas derivados das políticas e procedimentos da organização do cliente e do desenvolvedor, como, por exemplo, os requisitos de processo operacional. 
C) Definem os requisitos do processo de desenvolvimento, como, por exemplo, a linguagem de programação, o ambiente de desenvolvimento ou normas do processo a serem usadas. 
D) Abrangem todos os requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos reguladores, que definem o que deve ser feito para que o sistema seja aprovado para uso. 
E) Incluem os requisitos legais, que devem ser seguidos para garantir que o sistema opere dentro da lei, e os requisitos éticos, que asseguram que o sistema será aceitável para seus usuários e o público.
.
Aula 5: Identificação de Componente
IDENTIFICAÇÃO DE COMPONENTES 
A identificação de componentes é o primeiro processo da metodologia apresentada por esta disciplina, que está baseada nas boas práticas da arquitetura de sistemas. Seu objetivo é criar uma visualização inicial de todos os elementos envolvidos (modelos, métodos, objetos, componentes etc.) e como eles são integrados. Na figura, você vê a origem dessas informações e suas ligações.
Os artefatos gerados a partir desse primeiro processo são:
INTERFACE DE NEGOCIOS
ESPECIFICAÇÃO DE COMPONENTES E ARQUIT. DO SISTEMA.
INTERFACE SISTEMAS 
MODELO DE NEGOCIOS
ARTEFATOS E SUBPROCESSOS DE DESENVOLVIMENTO DO MODELO DE NEGÓCIOS 
Veja a seguir a definição dos artefatos, como cada sub processo é desenvolvido e o que devem conter cada um dos artefatos gerados. 
ARTEFATO MODELO DE NEGÓCIOS 
Baseado no modelo CANVAS de modelagem de negócios, é gerado a partir do molde proposto pela metodologia que estamos aplicando nesta disciplina.
SUBPROCESSO IDENTIFICAÇÃO DE INTERFACES DE NEGÓCIO 
Este subprocesso tem como objetivo a identificação, via modelo, das interfaces que mapearão as funcionalidades do sistema em relação à implementação do negócio a ser resolvido com o sistema a ser desenvolvido. 
ARTEFATO INTERFACE DE NEGÓCIOS 
O artefato gerado será um modelo que apresente todas as classes do sistema a ser desenvolvido e suas interfaces de utilização, mapeando como os atores farão os acessos ao sistema e que tipo de funcionalidade estará disponível para cada um deles.
SUBPROCESSO IDENTIFICAÇÃO DE INTERFACES DE SISTEMAS E REGRAS DE NEGÓCIO 
Neste subprocesso, é necessário identificar como os componentes de sistema serão interligados de maneira a resolver o proposto no modelo de negócio, para o novo sistema a ser desenvolvido. É necessário que todos os elementos estejam mapeados e suas ligações definidas, de maneira a se conseguir uma visão sistêmica entre os elementos e como eles resolvem as regras de negócio. 
ARTEFATO INTERFACE DE SISTEMAS 
O artefato gerado aqui, como mostra a imagem, traduz a necessidade de identificação dos componentes disponíveis e como eles serão interligados e resolverão as regras de negócio, para o novo sistema a ser desenvolvimento.
SUBPROCESSO ESPECIFICAÇÃO DE COMPONENTES E ARQUITETURA DO SISTEMA 
A partir da identificação das interfaces e da solução das regras de negócios, feitas no subprocesso anterior, é possível definir quais componentes já estão prontos e quais deverão ser desenvolvidos.
1.Sobre as características da engenharia de componentes, a alternativa INCORRETA é: 
A) Os riscos são menores ao usar um componente já existente em relação ao desenvolvimento de algo a partir do zero. 
B) Há aumento da produtividade, tendo em vista a redução de esforços pela equipe de desenvolvimento, seguindo a ideia “Crie uma vez, use onde quiser”. 
C) A qualidade e contabilidade do produto são maiores, pois o componente reutilizado já foi testado e aprovado. 
D) Mesmo no caso de componentes comercias, há sempre o acesso ao código-fonte e não há a preocupação com direitos autorais e licenças. 
E) Resistência da parte das equipes de desenvolvimento, pois exige forte padronização (investimento de tempo e controle de qualidade) e documentação (investir mais tempo nos artefatos). A adoção de novas práticas de desenvolvimento geralmente encontra forte resistência a mudanças por parte.
Aula 6: Interação de Componentes – Parte I
Interação de componentes A modelagem de interação de componentes é uma técnica de modelagem do comportamento dos componentes em relação ao problema a ser resolvido.
DEFINIR OPERAÇÕES DE NEGOCIO
O artefato de operações de negócio é a parte da modelagem de processos de negócios focada nas operações resultantes deste negócio, pois fornece uma solução clara e adaptável para capturar as especificações operacionais dos processos de negócio.Neste momento, o modelo de negócios é validado e as operações são representadas, de maneira que sejam vistas todas as relações de funcionamento do negócio que o sistema proposto está disposto a resolver.
REFINAR INTERFACES E REGRAS DE NEGÓCIO
Refinar as regras de negócio é o subprocesso responsável por revistar o modelo de negócios, alterando e adaptando os elementos na medida das necessidades, já que agora temos as informações das operações de negócio mapeadas e definidas.
REFINAR DEFINIÇÃO DE COMPONENTES E ARQUITETUA
A Neste subprocesso também se espera que o arquiteto de sistemas faça um refinamento do modelo feito previamente, com as informações de operações e do modelo de negócios mapeadas e definidas de forma definitiva.
Questão 1 
Sobre interação de componentes, analise as sentenças a seguir, verique quais são verdadeiras e depois marque a opçãocorrespondente: 
(I) Sempre que possível, a solução deve ser construída por meio de componentes já existentes, sendo eles componentes “comerciais de prateleira” (comercial off‐the‐shelf ‐ COTS) ou componentes implementados dentro da empresa (in‐house). 
(II) A equipe de desenvolvimento deve tentar modicar ou remover os requisitos do sistema que não puderem ser implementados como componentes COTS ou desenvolvidos internamente. 
(III) O desenvolvimento baseado em componentes é um tipo de desenvolvimento de software fortemente baseado no reuso. 
A) I e II estão corretas. 
B) I e III estão corretas. 
C) II e III estão corretas. 
D) I, II e III estão corretas. 
E) II está correta.
Questão 2 
Na interação entre os componentes, é necessário descobrir as operações de negócio que estão ligadas ao relacionamento entre os componentes, através de diagramas dinâmicos, como de colaboração, de sequência ou de atividades. 
Essa sentença é: 
A) Verdadeiro 
B) Falsa
Questão 3 
Na especicação nal dos componentes, o Modelo de Informação das Interfaces (Interface Information Model) é utilizado porque: 
Provê a relação entre cada interface e as entidades do modelo de negócio. 
(II) Ajuda o entendimento do contexto de cada interface. 
(III) Mantém o conhecimento do domínio somente com o desenvolvedor responsável pela informação. Das sentenças acima, qual está INCORRETA? 
A) I 
B) II 
C) III 
D) I e III 
E) II e III
Questão 4 
Fases: 
1 - Aquisição dos componentes; 
2 - Localização de componentes prontos; 
3 - Reutilização de componentes; 
4 - Implementação dos Componentes; 
Processos: 
I - Pode ser necessário adaptar os componentes reutilizados ou até mesmo as funcionalidades do sistema (renegociação dos requisitos); 
II - Reutilização de componentes prontos ou a utilização de novos componentes; 
III - Busca por serviço fornecido pelo componente, considerando a semelhança de seus conteúdos; 
IV- Deve-se utilizar um modelo de componente já existente, tais como EJB, COM+ etc. 
A alternativa que relaciona corretamente cada fase com seu processo é: 
A) 1-IV, 2-II, 3-III, 4-I 
B) 1-II, 2-III, 3-I, 4-IV 
C) 1-I, 2-II, 3-III, 4-IV 
D) 1-III, 2-IV, 3-II, 4-I
Questão 5 
Sobre a integração de componentes, a alternativa INCORRETA é: 
A) A fase de provisionamento dos componentes depende diretamente de tecnologia, pois define como os componentes serão adquiridos, localizados, reutilizados ou implementados. B) O processo UML Componentes lista possíveis maneiras de criar os componentes de software, aquisição, localização, reutilização e implementação de componentes 
C) Na montagem do sistema, também dependente da tecnologia, é feita a implementação dos conectores e a ligação entre os componentes e os conectores do sistema. 
D) Na integração dos componentes é observada a adaptação e o comportamento dos componentes, requisitos de qualidade, disponibilidade, escalabilidade, confiabilidade, entre outros. 
E) Após a integração dos componentes, eles não podem ser utilizados como módulos separados em sistemas futuros.
Questão 6 
Na fase de integração de componentes, há um compromisso de implementar e integrar os componentes de forma que eles sejam consistentes com a documentação para facilitar o reuso dos mesmos no futuro. 
Nesta atividade, são realizados os seguintes passos: 
De posse da documentação (modelos) dos componentes é definida qual a linguagem de implementação será utilizada. 
(II) Após isso, é realizada a implementação dos componentes e suas respectivas interfaces. 
(III) São realizados os testes dos componentes. 
(IV) Uma vez implementados, e testados, os componentes são armazenados no repositório para possível utilização na implementação de uma aplicação. 
Estão INCORRETAS as armações: 
A) I e II 
B) II e IV 
C) I e III 
D) II, III e IV 
E) Nenhuma armação está incorreta.
Aula 7: Interação de Componentes: Parte II
COMPLEXIDADE DE SISTEMAS
A função do arquiteto de sistemas é abstrair toda a complexidade do sistema em elementos encapsulados, de maneira de que o usuário final tenha um sistema amigável e de fácil uso. Ao mesmo tempo, esse sistema precisa resolver todos os problemas propostos, sem que o usuário perceba a complexidade embutida na aplicação. Para o usuário, a solução deve parecer simples e fácil, já que toda a complexidade deve estar escondida e resolvida pelos desenvolvedores, na direção definida pelo arquiteto de sistemas. 
A arquitetura de sistemas baseadas em componentes permite isso de maneira quase intuitiva. 
COMPONENTES DE UMA ARQUITETURA DE SISTEMAS
Segundo Garlan (2000), do ponto de vista do arquiteto de sistemas, os seguintes componentes fazem parte de uma arquitetura de sistemas:
BANCO DE DADOS/SEVIDORES/CLIENTE/FILTROS/UM OU MAIS COMPONENTES.
A interação entre eles pode ocorrer através de:
CHAMADAS DE PROCEDIMENTOS/ACESSO AVARIAVEIS/USO DE PROTOCOLOS PARA ACESSO A CLIENTES E SERVIDORES/BANCO DE DADOS/OUTROS EVENTOS QUAISQUER.
Os componentes de uma arquitetura de sistemas estão divididos em camadas estruturais, que, durante o desenvolvimento, devem ser consideradas de forma fundamental pelo arquiteto. Essas camadas estruturais são os pilares do desenvolvimento de sistemas por componentes. A partir delas é que se projeta a interação entre os componentes estruturais do sistema e se define a estrutura básica da arquitetura do sistema.
Nesse contexto, os componentes são inseridos nas camadas que controlam a interação dos componentes e cada componente se comunica com as camadas vizinhas.
VANTAGENS E DESVANTAGENS DO USO DE CAMADAS
Quando o arquiteto de sistemas decide utilizar camadas na arquitetura do sistema a ser desenvolvido, deve estar ciente dos fatores de vantagens e desvantagens desse tipo de abordagem.
VANTAGENS:
FACILIDADE DE COMPREENÇÃO
FACILIDADE DE MANUTENÇÃO
DESENVOLVIMENTO INDEPENDENTE
FACILIDADE DE REUTILIZAÇÃO
DESVANTAGENS:
DUPLICAÇÃO DE FUNCIONALIDADE 
DIFICULDADE DE ESTRUTURAR UM SISTEMAS ATRAVES DE CAMADAS
DESENVOLVIMENTO INDEPENDENTE
ELEMENTOS DA RUP (RATIONAL UNIFIED PROCESS)
A arquitetura de sistemas envolve uma série de decisões que definem como o sistema será utilizado e apoiará a organização destinatária dele.
Tem os seguintes objetivos: 
Definir os elementos e suas interfaces, de modo a estabelecer a estrutura do sistema; Estabelecer o comportamento associado entre os elementos que compõe o sistema; Analisar a composição desses elementos e suas estruturas, comportamentais e agregações de subsistemas.
ELEMENTOS DE IMPLEMENTAÇÃO QUE AFETAM A ARQUITETURA DE SISTEMAS
Veja os seguintes elementos influenciam o desenvolvimento de sistemas baseados em componentes e que, por consequência, influenciam na sua integração.
ARQUITETURA DE COMPUTADORES
SISTEMA OPERACIONAL
BANCO DE DADOS
PROTOCOLO DE REDE
LINGUAGEM DE PROGRAMAÇÃO
AMBIENTE DE INTERFACE GRAFICA
BIBLIOTECA DE FUNCÕES DISPONIVEIS
SISTEMAS LEGADOS
: Papel do arquiteto de sistemas na interação de componentes O arquiteto de sistemas deve conhecer os seguintes elementos que compõe o desenvolvimento baseado em componentes: 
• O negócio e os requisitos das aplicações a serem desenvolvidas; 
• Os componentes disponíveis no ambiente e nos sistemas instalado.
• As tecnologias disponíveis para construção e arquitetura de sistemas; 
• As metodologias de desenvolvimento adequadas ao sistema a ser desenvolvido
PADRÃO ARQUITETURA MVC (MODEL VIEW CONTROLLER) 
Quando o arquiteto de sistemas decide utilizar o padrão MVC para construir sua aplicação, deve levar em conta os seguintes aspectos:
MODEL
DEFINE A SEMANTICA DA APLICAÇÃO E DEFINE SEU COMPORTAMENTO
VIEW
DEFINE A APRESENTAÇÃO VISUAL DA APLICAÇÃO
CONTROLE
GERENCIA DE INTERAÇÃO DA APRESENTAÇÃO VISUAL (VIEW) COM OS COMPORTAMENTOS DA APLICAÇÃO (MODEL).
INTERAÇÃO DE COMPONENTES COM AOS (ARQUITETURA ORIENTADA A SERVIÇOS)
Na arquitetura de sistemas orientada a serviços, todas as funcionalidades do sistema devem ser disponibilizadas na forma de serviços. Esses serviços seconectam através de um barramento de serviços (ESB). Nesse barramento são disponibilizadas as interfaces na forma de web services que interagem com o repositório de dados.
Exercício Sobre “chamada de procedimento/método”, é correto armar que: 
A) Segue o modelo Cliente/Servidor. 
B) Um componente que fornece uma interface com procedimentos/métodos para solicitar a execução de seus serviços é um servidor. 
C) Componentes/aplicações que utilizam os serviços de outros componentes são seus clientes. 
D) Todas as alternativas estão corretas.
Aula 8: Especificação de componentes
Um dos pontos mais críticos no desenvolvimento de um sistema é o momento em que os desenvolvedores têm que traduzir os requisitos levantados junto às partes interessadas, em especificações que façam sentido para os programadores, já que nem sempre as informações repassadas pelas partes interessadas vão estar de acordo com as normas para desenvolvimento.
DEFINIÇÃO DE ESPECIFICAÇÃO DE COMPONENTES
Para entendermos os conceitos de especificação de componentes, é necessário compreender quais os elementos estão relacionados a um componente. Vamos começar conhecendo as características de um componente:
TEM UMA ESPECIFICAÇÃO
PODE SER DISTRIBUIDO
PODE SER EMPACOTADO EM MODULOS
DEVE SER ADERENTE A PADRÕES
DEVE SER ADETEM UMA EMPLEMENTAÇÃO QUE DEVE SER BASEADO EM TODOS OS ELEMENTOS ANTERIORES.
TIPOS DE COMPONENTES
OBJETO DE SISTEMA PRONTOS
SGDB
ELEMENTOS DE COMUNICAÇÃO
COMPONENTES SEREM DESENVOLVIDOS PARA O SISTEMA
ESPECIFICAÇÃO DE COMPONENTES A SEREM DESENVOLVIDOS
Como vimos anteriormente nesta aula, especificar um componente pode ser definido como o processo de traduzir as necessidades das partes interessadas em uma linguagem que os desenvolvedores entendam e consigam implementar. Durante esse processo, é necessário que o arquiteto de sistemas complete as informações técnicas necessárias que as partes interessadas não conseguem informar, baseado em seu framework de conhecimentos. Esse processo pode ser melhor entendido quando observamos a imagem ao lado
METODOLOGIA/PADRÕES
O arquiteto de sistemas deve se preocupar com os seguintes conceitos quando for especificar um componente.
EMPACOTAMENTO DE COMPONENTES
Uma das mais úteis ferramentas do desenvolvimento de sistemas por componentes é o empacotamento. Com esse recurso, o arquiteto consegue resolver o sistema, abstraindo conceitos de mais alto nível, sem se preocupar muito com os conteúdos dos objetos, mas, sim, com sua funcionalidade. Nesse caso especificamente, os componentes são reunidos por funcionalidade em pacotes que auxiliam muito o arquiteto em sua tarefa de resolver os problemas das partes interessadas.
DISTRIBUIÇÃO DE COMPONENTE
O arquiteto de sistemas deve ter a preocupação de definir e construir middlewares que conectem as diversas camadas de componentes e, consequentemente, os componentes, de maneira a conseguir uma forte acoplagem para a organização. Os componentes devem ser distribuídos em containers seguindo as políticas estabelecidas pelos middlewares, ou seja, dentro de um mesmo container somente podem existir componentes que atendam a mesma configuração. Essa configuração está presente nos descritores de distribuição que, geralmente, são escritos em XML e devem conter informações suficientes para Que:
OS COMPONENTES SEJAM CORRETAMENTES CONECTADOS
AS CAMADAS CONTENHAM OS NIVEIS CORRETOS DE SUPORTE DE CONFIGURAÇÃO
OS NIVEIS DE SEGURANÇA CORRETOS PARA APLICAÇÃO ESTEJAM IMPLEMENTADOS
IMPLEMENTAÇÃO DE COMPONENTES
A implementação de componentes é tarefa dos programadores, mas o arquiteto de sistemas também tem sua parcela de responsabilidade neste contexto, gerando especificações que atendam às necessidades e sigam os padrões definidos pela organização. Outro conjunto de participantes nesse contexto é a área de garantia e controle da qualidade, que tem a função de prover elementos que garantam a qualidade dos componentes produzidos.
Exercício No tocante ao desenvolvimento de software orientado ao reuso, embora o estágio inicial de especificação de requisitos e o estágio de validação sejam comparáveis com outros processos, os estágios intermediários em um processo orientado ao reuso são diferentes. Nesse caso, são processos em estágios intermediários: 
A) Projeto de interface, análise de componentes, projeto arquitetural e testes de aceitação. 
B) Análise de componentes, modificação de requisitos, projeta de sistemas com reuso e desenvolvimento e integração. 
C) Desenvolvimento de protótipo, projeto arquitetural, análise de componentes e plano de teste. 
D) Especificação de sistema, avaliação de mudanças, análise de componentes e desenvolvimento e integração.
Na arquitetura de sistemas, determinado conceito permite que, entre dois elementos de software A e B, seja possível postular alguma mudança de A, que pediria que B fosse mudado (ou, no mínimo, cuidadosamente verificado), a m de preservar a exatidão global e também postular alguma mudança, que pediria que tanto A como B mudassem juntos para preservar a exatidão global. Isso trata-se do conceito de: 
A) Polimorsmo. 
B) Congeneridade. 
C) Mutabilidade. 
D) Polidepen
Aula 9: Provisionamento e Construção – Parte I
A construção de componentes é o último processo da metodologia apresentada por esta disciplina e visa construir os componentes definidos pelo arquiteto de sistemas para a solução do problemas apresentados pelas partes interessadas. Aqui nós veremos, dentro deste processo, o passo a passo para que seja feita uma construção limpa e dentro dos padrões, seguindo as boas práticas de arquitetura de sistemas. Nesta aula, então, apresentaremos a maneira como os programadores devem lidar com a construção de componentes e a sua relação com os resultados a serem alcançados. Dessa forma, cará evidente a importância de sua aplicação no contexto da arquitetura de sistema.
COMPONENTES
Um dos conceitos mestres na arquitetura de sistemas baseada em componentes (glossário) é que um componente é definido e construído para fornecer um certo nível de serviço. Como vimos nas aulas anteriores, teremos os componentes separados em função dos grupos de serviços que eles oferecem. Teremos componentes de hardware, de sistema operacional, de SGDB, de aplicativos comerciais e de sistemas da própria corporação já desenvolvidos. O arquiteto de sistemas, baseado nos requisitos do novo sistema, vai executar o design da nova aplicação, identificando todos os componentes necessários e aplicando reuso aos componentes que já existirem. Somente serão construídos os componentes que não existirem. É importante que o arquiteto de sistemas conduza a definição e a construção desses novos componentes, de maneira que eles passem a fazer parte do conjunto de componentes a serem reutilizados no futuro.
AMBIENTE DE COMPONENTES 
Um ambiente componente é um meio ambiente de objetos distribuídos. Os componentes devem estar em conformidade a um conjunto de regras padrão para que se possa operar nesse ambiente, e um conjunto de serviços de infraestrutura (suporte a transações, segurança, concorrência e assim por diante), na qual o componente de aplicação pode depender. Fazemos isso pois os frameworks são os mais indicados para fornecer uma base mais sólida para a próxima geração de aplicativos baseados em componentes distribuídos, em escala empresarial. Nesse contexto, temos as seguintes opções:
AMBIENTE DE COMPONENTES
MICROSOFT COM+
ENTERPRISE JAVABEANS EJB
DEPENDENCIA DE PLATAFORMA
WINDOWS / NENHUMA
DEPENDENCIA DE LINGUAGEM
NENHUMA
JAVA 
Nesta disciplina, não vamos fazer análise de qual ambiente é melhor e em que condição tampouco vai direcionar qual dos dois devem ou não ser usados. Aqui vamos nos limitar a relatar os conceitos de uso dos frameworks sem a preocupação de detalhar particularidades de cada um deles. 
FRAMEWORK CCM – CORBA COMPONENT MODEL 
O CCM é um framework de componentes do lado do servidor, cuja finalidade é facilitaro desenvolvimento e a instalação de aplicações distribuídas que utilizam a arquitetura de sistemas por componentes. Esses componentes podem ser de diversos tipos, como vimos nas aulas anteriores. 
Nível de componentes do CCM O CCM é dividido em dois níveis de componentes: 
NÍVEL BÁSICO 
Provê uma forma simplificada de distribuir um objeto CORBA como componente. 
NÍVEL ESTENDIDO 
Provê um conjunto maior de ações, como as portas de comunicação que representam os elementos de conexão entre os componentes. 
Cinco tipos de modelos do CCM O CCM são também estruturados em cinco tipos de modelos: MODELO ABSTRATO 
Definem os atributos, portas de comunicação e home dos componentes. 
MODELO DE PROGRAMAÇÃO 
Composto pela CIDL (Component Implementation Denition Language) e pelo CIF (Component Implementation Framework). 
MODELO DE EMPACOTAMENTO Especifica como os componentes e suas implementações devem ser empacotados. 
MODELO DE INSTALAÇÃO Define um mecanismo padrão para a instalação de aplicações. MODELO DE EXECUÇÃO Define o ambiente de execução para as instâncias do componente.
 ARQUIVOS CIDL 
Os seguintes elementos são especificados em um arquivo CIDL, no contexto do desenvolvimento na arquitetura de sistemas por componentes.
ARQUIVOS CIF 
O CCM define um grande número para suportar a estrutura e funcionalidade dos componentes. 
As implementações de muitas dessas interfaces podem ser geradas automaticamente. É nesse contexto que apresenta-se o CORBA - Component Implementation Framework (CIF). 
CCM define uma linguagem declarativa, Component Implementation Denition Language (CIDL), para descrever implementações e persistência de estado de componentes e home. 
CIF usa a CIDL para gerar skeletons que automatizam tarefas básicas, como navegação, ativação e gerenciamento de estado.
CONTAINERS
Os componentes são empacotados em DLLs e executados em servidores de componentes. 
As implementações dos componentes dependem dos conceitos da programação orientada a aspectos para encaminhar requisições de clientes para os elementos de servidor. 
Os componentes não precisam saber como tratar problemas, como a criação de hierarquia de POAs, e localizar serviços do CCM. 
Funcionalidades: Para isso, foram definidos os containers, com as seguintes funcionalidades:
ATIVAÇÃO/DESATIVAÇÃO DE IMPLEMENTAÇÃO DE COMPONENTES, PRESERVANDO RECURSO (COMO MEMÓRIA)
FORNECIMENTO DE CAMADAS DE ADAPTAÇÃO COM OS SERVIÇOS DE TRANSAÇÃO, PERSISTENCIA, SEGURANÇA E NOTIFICAÇÃO.
FORNENCIMENTO DE CAMADA DE ADAPTAÇÃO PARA CALL-BACKS 
GERENCIAMENTO DE POLITICOS DO POA.
Gerenciamento do ciclo de vida 
O gerenciamento do ciclo de vida dos componentes de servidor é feito através de políticas que controlam o momento de ativação/desativação dos componentes: 
EMPACOTAMENTOS E DISTRIBUIÇÃO
Em sistemas distribuídos, componentes podem ser implantados em diversos servidores e sistemas operacionais. Além disso, um componente pode depender de outros componentes, tornando o processo de empacotamento e distribuição bem mais complicado do que se imagina. 
CCM descreve componentes e suas dependências usando Open Software Description (OSD), que é um XML Document Type Denition (DTD) denido pelo consórcio www. 
Componentes são empacotados em DLLs. Package descriptors são documentos XML em conformidade com o OSD e DTD, descrevendo o conteúdo da DLL e suas dependências. 
CCM e OSD também definem component assembly descriptors, que descrevem instruções de implantação e topologia dos componentes, e têm como objetivo o suporte à implantação automática dos componentes.
Exercício 1. Na construção dos componentes de um domínio do problema, há três passos principais. Assinale a alternativa que corresponde à ordem correta de criação desses passos: 
A) Instalar componentes, gerar código dos componentes e modelar componentes. 
B) Gerar código dos componentes, modelares componentes e instalar componentes. 
C) Modelar componentes, gerar código dos componentes e instalar componentes. 
D) Modelar componentes, instalar componentes e gerar código dos componentes.
Exercício 2. A etapa “modelar componentes” é dividida em três passos: definir domínio do problema, especificar componentes e projetar componentes. Assinale a alternativa que não corresponde à especificação de cada um dos passos dessa etapa: 
A) No passo “definir domínio do problema”, obtêm-se as especificações UML do domínio do problema a partir estudo do conhecimento do domínio do problema. 
B) No passo “especificar componentes”, obtêm-se os componentes especificados usando técnicas de DBC. 
C) No passo “projetar componentes”, faz-se o projeto interno dos componentes, usando técnicas de DBC do método Catalysis [D Souza, 1999]. 
D) No passo “especificar componentes”, as atividades são realizadas no nível de abstração do projeto interno de componentes.
Aula 10: Provisionamento e Construção – Parte II
ESPECIFICAÇÃO DE COMPONENTES X CONSTRUÇÃO DE COMPONENTES 
Em UML, um componente realiza uma ou mais interfaces. Como já discutimos antes, isso é suficiente para modelar alguns dos detalhes da tecnologia de implementação de componentes. Para lidar com especificação, nós adicionamos alguns estereótipos UML, como especificação de componentes, as classes e suas interfaces. Uma especificação de componente oferece um ou mais tipos de interfaces, por isso há uma correspondência bastante simples entre os elementos de especificação e os elementos de execução. UML também define a relação entre o componente e uma interface através de relacionamentos.
MAPEAMENTO DE CONSTRUÇÃO E RESTRIÇÕES 
Os principais problemas com mapeamento de construção e restrições com componentes de tecnologia surgem a partir das seguintes considerações.
TIPO DE PARAMETRO OPERAÇÃO, TIPO (IN/OUT/INOUT/VOLTA) E DE REFERENCIA DAS RESTRIÇOES. 
MECANISMO DE MANIPULAÇÃO DE EXERÇÃO E DE ERRO
RESTRIÇOES HERANÇA DE INTERFACE E SUPORTE
SEQUENCIA DE OPERAÇÃO 
PROPRIEDADE DE INTERFACE 
MECANISMO DE CRIAÇÃO DO OBJETO
DISPONIBILIZAR EVENTOS
HERANÇAS DE INTERFACE E SUPORTE DE INTERFACES 
Há uma diferença enorme entre o COM + e EJB, quando se trata de herança de interface e suporte de interações.
PROPRIEDADES DE INTERFACES 
No COM +, uma propriedade de interface é a especificação abreviada para um get e um set, como um par de operações. Ao usarmos UML para especificar interfaces, definimos que um atributo de interface existe puramente por apoiar a especificação de pré e pós-condições de operações, e você deve, explicitamente, definir quais operações deseja. Por exemplo, a interface base COM + IUnknown tem duas operações para o gerenciamento de contagens de referência.
ADDREF ( ) RELEASE ( )
A especificação dessas operações tem de se referir ao atributo de interface “contagem de referência”. Porém, no COM +, definir tal atributo significa, de forma indireta, definir a existência de operações de acesso. Ambos os processos estão diretamente relacionados, o que pode nos trazer problemas. 
CRIAÇÃO DE OBJETOS 
Tanto no EJB como no COM + usamos uma abordagem de fábrica de objetos, onde um objeto componente é utilizado para criar instâncias de outro componente. No EJB, a fábrica é o objeto inicial. 
No COM +, é objeto IClassFactory. 
No COM +, há muita flexibilidade sobre o qual objeto é a fábrica. Isso é feito simplesmente designando um componente que disponibiliza o IClassFactory relevante para uma dada classe. 
Esse mesmo elemento também pode fazer outras coisas, e, neste caso, você deve disponibilizar uma funcionalidade para o mesmo.
CORRESPONDÊNCIAS DA ARQUITETURA DA APLICAÇÃO 
Apresentamos aqui uma série de camadas distintas na arquitetura de aplicação, onde cada camada contém diferentes responsabilidades. Vamos agora indicar brevemente como certas características de especificação dessas camadas podem ser mapeadas para as tecnologias-alvo. É evidente que as considerações detalhadas de uma arquitetura de sistemas por componentes são muito extensas. Porisso, nos limitamos a algumas observações gerais sobre o uso de sessão e de entidade EJBs (essa distinção não existe no Com +) e quais as propriedades de transação devem ser utilizado.
SUBCOMPONENTES
Uma especificação é um componente que encapsula a sua funcionalidade (sob a forma de uma ou mais interfaces) que correspondem a uma única unidade de execução. Isso define a unidade de fornecimento e substituição na arquitetura de aplicativos, geralmente provisionando e substituindo requisitos de granularidade para uma aplicação de negócios de grande escala. No entanto, às vezes, queremos apresentar um modelo de objetos mais rico e detalhado ao cliente, sem a introdução de um enorme conjunto de componentes separados, cada um agindo de forma isolada. Como podemos, então, equilibrar a necessidade de definir um componente de forma mais grosseira para efeitos de provisionamento e de forma mais detalhada para a especificação e uso?
Instâncias são criadas por operações específicas Subcomponentes não têm objetos de fábrica explícitos como os componentes. Em vez disso, suas instâncias são criadas por operações específicas do componente pai ou irmão. Por exemplo, a operação ICustomerMgt :: createCustomer () iria criar uma instância do subcomponente do cliente. Subcomponente objeto estado share com o seu componente, passando a existir somente em tempo de execução. Um componente e todos os seus subcomponentes devem ser embalados em conjunto para o mesmo módulo (.exe, .dll .jar)
INTERAÇÃO COM SISTEMAS EXISTENTES
Em alguns momentos de nossa disciplina, tratamos do desenvolvimento somente utilizando o conceito de novos componentes. Porém, no mundo real, quando utilizamos a arquitetura de sistemas por componentes, a maioria dos componentes já está prontos em sistemas existentes ou em aplicativos de prateleira. Para os casos de utilização de componentes prontos, devemos fazê-lo através de APIs, disponibilizadas por esses componentes. Todos os elementos de interação com os componentes prontos devem ser feitos através de interfaces, que precisam ser bem especificadas e definidas para não deixar dúvidas de seus usos e de seus resultados.
CONSTRUÇÃO 
A construção é o processo de reunir componentes de software existentes ativos em um ambiente de TI e projetar uma interface de usuário para esse sistema, com base nos modelos para formar uma aplicação. A construção compartilha várias das características presentes na configuração padrão do ambiente, principalmente no que se refere a práticas de gerenciamento. Cada componente individual disponível pode ser visto como um item de configuração separado a ser utilizado, mantendo-se um controle de versão.
Sobre “projetar componentes”, assinale a alternativa cujo projeto NÃO faz parte deste passo: 
A) Projeto do modelo de classes. 
B) Projeto do modelo de casos de uso. 
C) Projeto do modelo de dados. 
D) Projeto do modelo de componentes.