Aulas 01a10 Arquitetura de Sistemas Estacio com info das Web Aulas

Prévia do material em texto

Aula 01
Componentes de Sistemas
Menu
01
02
03
04
05
06
07
08
09
10
1. Identificar os Fundamentos e Objetivos de um Componente;
2. Apresentar um Exemplo de Componente e Definir o que não é um Componente;
3. Correlacionar Arquitetura de Sistemas e Arquitetura de Componentes;
4. Entender Especificação de Componentes, Implementação de Componentes e Níveis de Modelo.
Fundamentos de um Componente
Objetivos
Arquitetura
Especificação 
Ex
 
 
01
02
03
04
05
06
07
08
09
10
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, integra-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ão relacionados 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.
3
Introdução
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Aula 03
APLICANDO UML
1- Entender como os Modelos UML ajudam no Desenvolv. de SW por Componentes;
2- Estudar a Utilização de UML na Arquitetura de Sist. Modelados por Componentes;
3- Compreender como os Modelos UML Ajudam no Processo de Desenvolvimento e 
 Garantem mais Confiabilidade ao Conceito de Arquitetura de Sistemas.
Menu
01
02
03
04
05
06
07
08
09
10
O problema científico: Realização da pesquisa bibliográfica e sua discussão.
As técnicas para a pesquisa bibliográfica e sua discussão.
 
 
01
02
03
04
05
06
07
08
09
10
Quando pensamos em componentes a partir de suas interfaces, criamos um número maior de possibilidades de uso e reduzimos significativamente o número de mudanças futuras.
A partir de um objeto simples estruturado (componente), é necessário combinar funcionalidade e dados para resolver os problemas em sistemas computacionais.
O grande desafio 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.
Objetivo de Componentes
Objetos simples, combinando funcionalidades;
Identificação das interfaces dos componentes;
Pensar componentes a partir de suas interfaces aumenta as possibilidades de reuso;
Componentes para resolver problemas de forma natural – depende da experiência.
7
Fonte: https://www.arduino.cc
Sobre o segundo item das características dos componentes (próximo slide), como mostra a imagem para sistemas de automação, componentes eletrônicos têm as mesmas características de componentes de sistemas:
Fundamentos de um Componente
Objetivos
Arquitetura
Especificação 
Ex
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Aula 05
Identificação de Componentes
Menu
01
02
03
04
05
06
07
08
09
10
69
Entender a Importância da Identificação de Componentes para um Melhor Resultado na Arquitetura de Sistemas;
Estudar os Elementos que Compõe a Identificação de Componentes como Primeiro Processo da Metodologia aqui Apresentada;
Compreender a Relação entre a Identificação de Componentes e os Outros Processos da Metodologia Apresentada na Disciplina.
 
 
01
02
03
04
05
06
07
08
09
10
Aula 06
Interação de Componentes – Parte I
Menu
01
02
03
04
05
06
07
08
09
10
80
Entender a Importância das Definições de Interface e Interação de Componentes para um Melhor Resultado na Arquitetura de Sistemas;
Estudar como são Definidos e Implementados os Elementos de Interação de Componentes na Arquitetura de Sistemas;
Compreender como estes Elementos de Interação Contribuem para o Sucesso do Projeto.
 
 
01
02
03
04
05
06
07
08
09
10
Aula 07
Interação de Componentes – Parte II
Menu
01
02
03
04
05
06
07
08
09
10
Entender a Importância das Definições de Interface e Interação de 
 Componentes para um Melhor Resultado na Arquitetura de Sistemas;
2. Estudar como são Definidos e Implementados os Elementos de 
 Interação de Componentes na Arquitetura de Sistemas;
3. Compreender como estes Elementos de Interação Contribuem para o 
 Sucesso do Projeto.
 
 
01
02
03
04
05
06
07
08
09
10
Aula 09
Provisionamento e Construção – Parte I
Menu
01
02
03
04
05
06
07
08
09
10
120
Entender a Importância do Provisionamento e Construção de Componentes para um Melhor Resultado na Arquitetura de Sistemas;
Estudar os elementos que Compõe a Etapa de Construção de Componentes como parte Integrante da Metodologia Apresentada na Disciplina;
Compreender a relação entre Construção de Componentes e os Outros Processos.
 
 
01
02
03
04
05
06
07
08
09
10
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 este 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, para ser classificado como componente.
10
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Aula 10
Provisionamento e Construção - Parte II
Menu
01
02
03
04
05
06
07
08
09
10
132
Continuar o entendimento da Importância do Provisionamento e Construção de Componentes para um Melhor Resultado na Arquitetura de Sistemas;
Estudar os elementos que Compõe a Etapa de Construção de Componentes como parte Integrante da Metodologia Apresentada;
Compreender a relação entre Construção de Componentes e os Outros Processos.
 
 
01
02
03
04
05
06
07
08
09
10
Componentes, no contexto da arquitetura de sistemas, são unidades de software estruturados 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:
4
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 à mostra somente como acionar 
e o resultado a ser alcançado pelo acionamento.
Não importa para quem vai usar tal componente, como as coisas 
acontecem dentro dele, e, sim, se o resultado esperado foi alcançado.
Identidade
Cada componente encapsulado tem uma identidade única de dadose funções
e pode assumir estados pré-determinados.
Fundamentos de um Componente
Objetivos
Arquitetura
Especificação 
Ex
01
Fundamentos de Componentes
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Camadas da Arquitetura de Sistemas
13
Fonte: O Autor
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Níveis de Modelo
Um modelo de algo apresenta uma perspectiva ou visão resumida do que é do que permite aquela coisa;
É importante frisar que existem modelos conceituais mais fortes e modelos conceituais mais fracos.
Ex. Planta de Casa, Diagrama de Domínio de Software.
15
Categoria de Modelos
Modelo Conceitual – Independente do tipo de software ou de tecnologia, representam o problema a ser resolvido;
Modelo de Especificação – Representa os componentes desoftware a serem utilizados;
Modelo de Implementação – Informam os detalhes de implementação que devem estar presentes dentro dos códigos.
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos o conceito de componentes e como estes são definidos e interagem;
Apresentamos um exemplo de componente e definimos o que não é um componente;
Analisamos a especificação e implementação de componentes, quais os níveis de modelos no contexto da arquitetura de sistemas.
16
Próxima Aula
Definições e uso de Workflow;
O impacto do gerenciamento de processos;
As especificações de um Workflow.
02
01
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 1
17
Quando falamos de componentes na Arquitetura de Sistemas, estamos falando de objetos computacionais simples que podem ser ligados de maneira lógica para resolver problemas complexos. Neste contexto, podemos fazer um paralelo das imagens a seguir com este conceito?
Fonte: www.legosse.com.br
 
 
01
02
03
04
05
06
07
08
09
10
Introdução
Sempre que estamos iniciando em alguma atividade é muito importante que tenhamos um conjunto de informações iniciais, fornecidas por quem já tem experiência nestas atividades, para que o resultado seja positivo desde a primeira vez. 
Essas informações são chamadas de processos, que em conjunto, assumem a forma de metodologia.
19
O uso de metodologias nos garante um aumento na maturidade na condução dos projetos, mesmo quando os profissionais envolvidos não têm muita experiência. Isso se deve ao fato de as metodologias servirem de referência e de guia na condução dos trabalhos e nelas estarem contidas todas as boas práticas da área de referência.
Nesta aula, faremos contato com metodologias de gestão e metodologias de desenvolvimento e realizaremos a correlação entre as duas, seus usos e resultados a serem alcançados. Dessa maneira ficará evidente sua importância e sua aplicação no contexto da arquitetura de sistemas.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Workflow
20
Fonte: O Autor
Workflow representa a metodologia de desenvolvimento de sistemas baseada na metodologia RUP.
Parte-se da ideia do sistema, em seguida efetua-se a coleta de requisitos que, após 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.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
21
Fonte: PMBoK 5ª Ediçã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.
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.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
22
Gerenciamento de Processos
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
23
Fonte: 
PMBoK 5ª Edição
Gerenciamento de Processos
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
24
Fonte: 
PMBoK 5ª Edição
Gerenciamento de Processos
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
25
Fonte: PMBoK 5ª Edição
Gerenciamento de Processos
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
26
Fonte: PMBoK 5ª Edição
Gerenciamento de Processos
Conjunto de controles que deve ser desenvolvido em todas as etapas do projeto, da iniciação ao encerramento.
Gerenciar processos é melhorar a execução e o planejamento do projeto para garantir os 5 pilares: escopo, tempo, custo, qualidade e satisfação do cliente.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
27
Diferenças entre métodos
Em alguns mé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.
Atenção
Aqui nesta aula, nós faremos uma abordagem intermediária, onde se gasta no máximo 5% do esforço total do projeto com levantamento de requisitos e, ao mesmo tempo, garante-se que eles tenham sido bem definidos e validados.
Isso somente é possível com a prototipação para validar requisitos em tempo de modelagem conceitual.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
28
Fonte: O Autor
Levantamento de Requisitos
Fica claro que vão existir trabalhos de gestão e trabalhos de desenvolvimento.
Os dois tipos de trabalhos vão coexistir em workflows 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.
FASES
ENTREGAS
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Outro ponto importante em uma metodologia é o conjunto de padrões a serem seguidos para garantir o uso de boas práticas e que as funcionalidades sejam construídas conforme seus requisitos.
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, produzidos mais rapidamente garantindo sua efetividade;
É objetivo de uma metodologia definir de forma clara “quem”, “o que”, “quando”, “como”, e “onde” executar as ações de desenvolvimento de software.
29
Quem?
O que?
Quando?
Como?
Onde?
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Metodologia de Gestão
A Metodologia de Gestão deve contemplar quantas fases forem necessárias a garantir que todas as áreas de conhecimento serão abordadas e de forma a garantir que escopo, tempo, custos e qualidade atinjam os níveis de definidos pelas corporações como sendo os ideais.
30
As fases da metodologia devem seguir um modelo interativo e incremental. Nele, cada fase é dividida em uma ou mais interações que visam uma entrega ao final. Cada entrega de cada fase deve garantir que o resultado está como grau de maturidade necessário àquele momento do projeto.
 Exemplo das fases de um processo de desenvolvimento, testes e manutenções dos software
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
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 as integridade sejam respeitadas. 
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ãoconseguidos e que passam a poder ser reutilizados.
31
A interação de componentes é o momento onde 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.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
A arquitetura não deve ser efetivamente alterada nesta fase. Essa tarefa de especificação detalhada só 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.
Especificação de Componentes
É na fase final da especificação que ocorrem as especificações detalhadas das operações e as suas restrições. Para uma dada interface devem-se definir os potenciais estados dos componentes e suas assinaturas, em seguida, especificar as condições prévias e posteriores para as operações. Além disto são aqui levantadas as regras de negócios e restrições.
32
Além desses detalhes na especificação da interface, esta etapa também apresenta a especificação de restrições, que são específicas para um componente e determinam como as definições de tipo de interfaces individuais vão corresponder a cada elemento no contexto desse componente.
02
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos o conceito de metodologia de gestão na Arquitetura de Sistemas;
Apresentamos o uso de metodologias de desenvolvimento e abordamos dois exemplos dentro da Arquitetura de Sistemas;
Analisamos a integração entre as duas e seus resultados no que diz respeito a Arquitetura de Sistemas.
33
Próxima Aula
Utilização de UML na Arquitetura de Sistemas;
Seu impacto na criação e integração dos componentes de sistemas.
02
03
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
I. Quais são as três características de um projeto de desenvolvimento de software?
34
Atividade 2 (w)
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
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õem o desenvolvimento de um projeto.
As operações de um projeto.
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
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Quando falamos de metodologia estamos falando de método para se executar algo. Existem métodos para execução ligados ao produto que se quer gerar e métodos para execução ligados a gestão do que se quer gerar. A diferença entre eles está nos resultados de cada um. 
35
Atividade 2 (ppt)
Por exemplo, se seguirmos uma receita para fazer 1000 salgados estamos usando uma metodologia de produto e se ao mesmo tempo monitorarmos e controlarmos o tempo e o custo da produção estaremos utilizando uma metodologia de gestão. As duas servem para um melhor resultado do que queremos fazer, mas tem focos diferentes. 
Na imagem abaixo você consegue identificar o uso destas duas metodologias?
Fonte: slideplayer.com.br
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Uma metodologia de desenvolvimento de sistemas gera um conjunto de entregas que começam em modelos conceituais de negócio, que vão evoluindo para modelos de sistemas até chegarem à implementação e construção do sistema. Seguir esse conjunto de etapas ajuda muito para que os sistemas sejam mais eficazes e eficientes.
Como visto na aula anterior, o uso de metodologias nos garante o aumento na maturidade na condução dos projetos, mesmo quando os profissionais envolvidos não têm muita experiência. Isso se deve ao fato de as metodologias servirem de referência e de guia na condução dos trabalhos e nelas estarem contidas toda a boa prática da área de referência.
Nesta aula, faremos contato com a metodologia Unified Modeling Language (UML) para desenvolvimento de sistemas e veremos como seus modelos podem ser extremamente úteis no contexto da arquitetura de sistemas.
37
INTRODUÇÃO 
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Por que precisamos de UML na AS
38
Fonte: O Autor
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.
Mas lembre-se que o foco desta disciplina está nos aspectos externos de componentes de sistemas e não no desenvolvimento dos módulos internos, mesmo que eles também possam ser modelados utilizando UML.
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õem a isso atendem aos objetivos propostos nesta disciplina.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
UML e Suas Generalizações
39
Como atingir conformidade em requisitos com UML?
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Conformidade de Requisitos
40
Ao definirmos nossos componentes, é necessário que sejam geradas as especificações de comportamento destes componentes. 
É através destes comportamentos que vamos garantir que as funcionalidades levantadas, estejam implementadas e em conformidade com os requisitos validados pelos partes interessadas.
Ao definirmos o comportamento dos componentes, estamos sendo mais precisos em relação a integração do modelo e completos em relação a sua funcionalidade.
Ao efetuarmos os testes de comportamento, durante a homologação, estamos garantindo que a aplicação está 
 em conformidade com os requisitos.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
DIAGRAMA DE INTERAÇÃO DE COMPONENTES - É um diagrama de colaboração utilizado para interação entre componentes.
Técnicas de Modelagem UML
Veremos aqui como usaremos UML para modelar os vários artefatos necessários na modelagem de sistemas por componentes.
Estes artefatos vão servir aqui no contexto de nossa disciplina para modelar o negócio e o sistema, na forma Edos componentes que compõem a Arquitetura do Sistema.
41
Fonte: O Autor
Exemplo
Para modelarmos os conceitos de negócios, usaremos o diagrama de classes, pois ele descreve o modelo de conceito do negócio.
Outro exemplo é o diagrama de especificação de interface que apresenta a especificação das interfaces. Nesse mesmo caminho temos os seguintes modelos:
diagrama de modelo de negócio,
diagrama de componentes e diagrama de implantação.
Temos também as seguintes variações:
DIAGRAMA DE FUNCIONALIDADES DE INTERFACE - Descreve o modelo de negócio, suas interfaces e as regras de funcionalidades para essas interfaces.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Modelo Conceitualde 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. Visa a identificar e definir as relações existentes dentro do negócio. Usaremos o diagrama de classe UML para representá-lo, mas é importante ficar 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.
42
Modelo Conceitual de Sistemas
Diagrama de Casos de Uso;
Descrição de Casos de Uso;
Diagrama de Domínio.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Modelo Conceitual de Negócio
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.
43
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:
Podem ser associações entre atores e objetos, generalização entre atores ou generalizações (extends e includes) entre objetos.
Os relacionamentos ajudam a representaro negócio dentro do diagrama de casos de uso. 
Representados por um boneco e um rótulo com o nome do ator., que é um usuário humano ou um outro sistema computacional.
Representados por uma elipse e um rótulo com o nome do objeto. Um objeto define uma grande função do sistema. A implicação é que uma função pode ser estruturada em outras funções e, portanto, um objeto pode ser explodido em níveis mais baixos ou detalhados.
O primeiro tipo de relacionamento que veremos é a associação, que representa a que objeto(s) os atores se relacionam ou, ainda, como um segundo ator se relaciona com os mesmos objetos do primeiro, a que está relacionado.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
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.
44
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Descrição de casos de uso
Descrevem, geralmente na forma textual, as funcionalidades existentes no diagrama de casos de uso, na forma 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.
45
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
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.
46
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Especificação de Interface
A especificação de interfaces de componentes é a forma de descrever como os elementos que quiserem utilizar estes componentes devem acessá-lo:
sua assinatura, com os parâmetros e retornos oferecidos
quais os atributos que ele manipula e 
quais as funções disponíveis para uso.
47
Os componentes podem ser agrupados em pacotes, que reúnem componentes com funcionalidades e atributos complementares, dentro do conceito de família de componentes.
Estes pacotes vão apresentar as informações necessárias para que possam ser utilizados no conceito de arquitetura de componentes, por meio de suas funcionalidades e operações.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos os elementos de UML e como estes contribuem na Arquitetura de Sistemas;
Apresentamos o uso destes modelos para o desenvolvimento de sistemas com o conceito da Arquitetura de Componentes;
Analisamos a integração destes modelos e seus resultados no que diz respeito a Arquitetura de Sistemas.
48
Próxima Aula
A importância de Requisitos na Arquitetura de Sistemas;
O Impacto de Requisitos no desenvolvimento de sistemas por componentes.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Os modelos conceituais utilizados na UML garantem que os elementos de negócio, referente ao sistema que está sendo desenvolvido, sejam completamente mapeados e garantem também que haja uma migração consistente dos modelos conceituais de negócio para os modelos conceituais de sistemas.
Desta 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 este conceito e a construção de um equipamento, atendendo as normas da ABNT e definições do INMETRO?
49
Atividade 3 (ppt)
Fonte: http://www.inmetro.com.br
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 3 (w)
50
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
 
 
01
02
03
04
05
06
07
08
09
10
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
Atividade 3 (w)
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 afirmativas I e III são verdadeiras.
B) Somente as afirmativas II e III são verdadeiras. (objetos = casos de uso)
C) Somente as afirmativas I e II são verdadeiras.
D) As afirmativas I, II e III são verdadeiras.
E) Somente a alternativa I é verdadeira.
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:
51
 
 
01
02
03
04
05
06
07
08
09
10
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
Atividade 3 (w)
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 anteriores
Questão 5:
A atividade de análise de requisitos procura descobrir o que os stakeholdersde 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.
52
 
 
01
02
03
04
05
06
07
08
09
10
Atividade 3 (w)
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ção.
53
 
 
01
02
03
04
05
06
07
08
09
10
Podemos definir requisitos como condição ou exigência indispensável para um fim, uma ocupação e/ou uma realização. Sob esta ótica e as definições de Arquitetura de Sistemas é que vamos desenvolver o conteúdo desta aula.
Introdução
Algumas metodologias tratam requisitos de forma menor, entendendo que como estes vão mudar mesmo até o fim do projeto, não valeria a pena perder muito tempo neste trabalho. Outras metodologias, ao contrário, entendem que requisitos devem ser levantados completamente até a exaustão, independente do tempo necessário para isto.
55
Aqui nós veremos um conjunto de ações intermediárias destes dois conceitos. Faremos a apresentação do conceito que levantar muito bem os requisitos, é muito importante, e que estes devem ser validados através do conceito de prototipação e ao mesmo tempo não devem durar mais que 5% do tempo total do projeto.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
CONCEITO INTERMEDIÁRIO
Como dissemos, nesta disciplina, usaremos um conceito intermediário, em que o esforço total no processo de requisitos não pode ultrapassar os 5% do esforço total do projeto.
Além disso, os requisitos devem ser validados com mecanismo que seja eficiente e eficaz para esse fim. 
Essas definições de esforço e dos mecanismos veremos mais detalhadamente nos itens a seguir.
Diferenças no levantamento dos requisitos:
DIAGRAMA DE FUNCIONALIDADES DE INTERFACE
Algumas metodologias tratam requisitos de forma menor, pois entendem que, como mudarão até o fim do projeto, não vale a pena perder muito tempo com eles, nem dedicar muito esforço nesse trabalho.
Nesses casos, os usuários e a equipe de desenvolvimento são chamados para novas definições e validações em cada parte do sistema que fica pronta.
Lembrando que para essas metodologias, os modelos conceituais de negócios e de sistemas são suficientes para que todos os envolvidos possam, cada um dentro de sua área de conhecimento, validar o que foi feito até ali.
Isso não é uma verdade absoluta, pois dificilmente um usuário leigo vai conseguir validar requisitos frente a modelos conceituais (negócio e sistemas) feitos para os iniciados em arquitetura de sistemas.
56
REQUISITOS VISTOS COM MUITA IMPORTÂNCIA
Outras metodologias, ao contrário, entendem que os requisitos devem ser levantados completamente até a exaustão, independentemente do tempo necessário para isso.
Nesse caso, o processo se torna moroso, caro e muito frustrante para os usuários, já que eles têm de participar de intermináveis reuniões de definição, sem que os resultados sejam visíveis.
O mesmo ocorre com a equipe de desenvolvimento, que acaba por gastar muita energia e foco em algo que demora a ficar consistente.
No caso dessas metodologias, a validação de requisitos é feita através de textos longos e cansativos que dificilmente levarão os usuários a um correto entendimento de seus sistemas e a uma correta e consistente validação dos requisitos.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Definição de Requisitos
57
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 detalhadamente mais à frente.
O conhecimento adquirido aqui servirá para que nossas partes interessadas e nossas equipes de desenvolvimento não enfrentem o problema apresentado no quadrinho.
Podemos definir requisitos como condição ou exigência indispensável para um fim, uma ocupação e/ou uma realização. Sob esta ótica e as definições de Arquitetura de Sistemas é que vamos desenvolver o conteúdo desta aula.
Fonte: Domínio publico – Adaptação do Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Esforço Máximo e Resultados Esperados
58
É de se supor que gastar somente 5% do esforço do projeto em levantamento e validação de requisitos, como estamos propondo aqui nesta disciplina, nos leve a estar mais próximos das metodologias que dão pouca importância aos requisitos. Mas posso garantir que isto está longe de ser verdade.
Essa delimitação de esforço máximo está associado a direcionar os trabalhos ao que realmente é importante para levantamento e validação de requisitos e também com o uso de ferramentas e técnicas baseadas em boas práticas de gestão e desenvolvimento.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
IMPLÍCITOS E EXPLÍCITOS
Para os dois tipos de requisitos devemos, ainda, separá-los em:
• Requisitos implícitos, que são aqueles que o usuário vai conseguir externar e repassar à equipe de desenvolvimento;
• Requisitos implícitos, que são aqueles que o usuário não vai conseguir repassar, ou por falta de conhecimento ou por entender ser muito óbvio e julgar que não vale a pena falar.
Tipos de Requisitos
59
Fonte: O Autor
FUNCIONAIS E NÃO FUNCIONAIS
Podemos separar os requisitos em duas categorias:
• Requisitos funcionais: tratam do que o sistema deve fazer, de sua funcionalidade;
• Requisitos não funcionais: tratam dos critérios que suportam os requisitos funcionais.
Como, por exemplo, qualidade para o software, os requisitos de performance, usabilidade, confiabilidade, robustez etc. Ou, então, os critérios relativos à qualidade para o processo de software ou uso de metodologias.
Para complementar as informações faltantes (requisitos implícitos), é necessário que a equipe de desenvolvimento tenha um framework de conhecimentos bem vasto. Dessa maneira, é capaz de preencher as lacunas, tanto para requisitos funcionais como para requisitos não funcionais.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Framework de Conhecimentos em TI como base para Requisitos
60
O framework de conhecimentos em TI que aqui referenciamos refere-se aos conhecimentos que vão além dos requisitos, como por exemplo: Infraestrutura de Hardware; Banco de Dados; Comunicação; Confiabilidade do Sistema; Nível de criticidade das operações; Desempenho do Sistema; Adequações legais e éticas; Segurança.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Técnicas de Levantamento de Requisitos
61
Reuniões de levantamento de requisitos.
 Duração máxima de 2 horas;
Separar as reuniões por camada de desenvolvimento, conforme previsto no conceito de arquitetura de sistemas (Dados, Negócios e Interface);
Convocação de usuários que consigam responder sobre cada uma das camadas;
No máximo 3 reuniões com cada grupo de usuários.
Ao finaldesses passos você terá os requisitos levantados de forma consistente, sem excesso de tempo.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Pré-Validação de Requisitos
62
Convoque uma reunião de 2h com as partes interessadas do seu projeto;
Separe os partes interessadas em grupos de 4;
Gere uma cópia do documento de requisitos para cada um dos grupos;
Cada grupo deve revisar o documento por, no máximo, 15 minutos;
Fazer com que todos os grupos revisem todas as cópias dos documentos;
Ao final destes passos você terá seus requisitos validados por todos os partes interessadas no projeto, além disto conseguira o apoio e patrocínio necessário, pois todos são responsáveis pelo documento gerado e não somente a equipe de desenvolvimento. A nomenclatura técnica desta técnica é: “Técnica de Delphi”
PROTOTIPAÇÃO
A prototipação é a melhor maneira de se validar requisitos, com esta técnica conseguimos criar um modelo conceitual forte para ser validado pelos partes interessadas.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Modelos Conceituais
63
Fonte: O Autor
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, fica mais fácil entender o conceito proposto.
Por exemplo, se usarmos como base para exemplificar um modelo conceitual forte, podemos 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.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
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.
Modelo Conceitual Fraco
64
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Como criar para a TI um modelo conceitual forte?
65
Como criar para área de TI um modelo conceitual forte, que seja facilmente 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.
É importante deixar claro às partes interessadas leigas que o protótipo é somente a casca e serve para validar funcionalidade e que ainda existe muito trabalho a ser feito para que o sistema fique pronto.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Como resultado final deste conjunto de processos, espera-se que todas as necessidades dos partes interessadas estejam presentes no sistemas desenvolvidos, na forma de funcionalidades, restrições e uso de tecnologias.
É de responsabilidade da equipe de desenvolvimento o atingimento dos resultados esperados.
Modelagem conceitual a partir de requisitos
66
Fonte: O Autor
Modelagem conceitual de negócios e de sistemas a partir dos requisitos validados
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 anterior.
Resultados Esperados
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Vimos o conceito de requisitos dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na definição de requisitos no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
67
Síntese da Aula
Próxima Aula
Identificação de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 4 (ppt)
68
Nesta aula vimos a importância de requisitos para o sucesso do desenvolvimento de sistemas de acordo com os conceitos da Arquitetura de Sistemas. Mas do ponto de vista de usuário, você acha que podemos associar os requisitos de sistemas a imagem a seguir? 
Fonte:
 http://ufpe.com.br/cienciadacomputacao/requisitos
 
 
01
02
03
04
05
06
07
08
09
10
Identificar componentes é o primeiro processo da metodologia apresentada por esta disciplina, e visa fazer com que o Arquiteto de Sistemas tenha um processo formal em que vai avaliar todas as estruturas, componentes e módulos disponíveis para a construção do modelo do sistema a ser desenvolvido.
Nesta aula então, apresentaremos a maneira que o Arquiteto de Sistemas deve lidar com a identificação de componentes, e a sua relação os resultados a serem alcançados. Desta maneira ficará evidente sua importância de sua aplicação no contexto da Arquitetura de Sistemas.
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, e tem por objetivo criar uma visualização inicial de todos os elementos envolvidos (modelos, métodos, objetos, componentes, etc...), como estes são integrados.
70
INTRODUÇÃO 
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
71
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, e tem por objetivo criar uma visualização inicial de todos os elementos envolvidos (modelos, métodos, objetos, componentes, etc...), como estes são integrados.
Identificação de Componentes
Fonte: O Autor
Os artefatos gerados a partir deste primeiro processo são, Interface de Negócios, Especificação de Componentes e Arquitetura do Sistema, Interface de Sistemas e o Modelo de Negócios. 
Veremos a seguir como cada sub processo é desenvolvido e o que devem conter cada um dos artefatos gerados.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Artefatos e subprocessos de desenvolvimento do modelo de negócios
Veja a seguir a definição dos artefatos, como cada subprocesso é desenvolvido e o que devem conter cada um dos artefatos gerados.
Modelo de Negócio
72
Temos que separar o modelo de negócios em grandes grupos que estão associados as seguintes perguntas: 
Como – Definem os recursos chaves, as atividades chave e os componentes prontos que podem ser utilizados no novo sistema;
O que – Define qual ou quais problemas o sistema deve resolver depois que ficar pronto;
Para Quem – Definem os principais usuários do sistema, quais os seguimentos de atuação do cliente que o sistema vai rodar e quais os elementos de infraestrutura devem ser utilizados pelo sistema a ser desenvolvido;
Quanto – Informações sobre custo computacional e criticidade do sistema e quais os benefícios se espera alcançar com o sistema a ser desenvolvido
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Artefato Modelo de Negócios
73
Fonte: O Autor
Baseado no modelo CANVAS de modelagem de negócios, é gerado a partir do molde proposto pela metodologia que estamos aplicando nesta disciplina.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
74
Este subprocesso tem como objetivo a identificação, via modelo, das interfaces que irão mapear as funcionalidades do sistema em relação a implementação do negócio a ser resolvido como osistema a ser desenvolvido.
Identificação de Interfaces de Negócio
Fonte: O Autor
Artefato Identificação de Interfaces de Negócio
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. Informações mapeadas abaixo:
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Identificação de Interfaces de Sistemas e Regras de Negócio
75
Este subprocesso identifica como os componentes de sistema serão interligados para resolver o proposto no modelo de negócio. É necessário que todos os elementos estejam mapeados e suas ligações definidas, de maneira a conseguirmos uma visão sistêmica entre os elementos e como estes resolvem as regras de negócio.
Artefato Interfaces 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 desenvolvido.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
76
Especificação de Componentes e Arquitetura de Sistemas
Artefato Especificação de Componentes e Arquitetura
Fonte: O Autor
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.
Todas essas informações devem estar representadas no artefato gerado a seguir.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Vimos o conceito de identificação de componentes dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na identificação de componentes no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
77
Síntese da Aula
Interação de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
Próxima Aula
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Sobre as características da engenharia de componentes, a alternativa INCORRETA é:
78
Atividade 5 (ppt)
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 confiabilidade 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 da equipe.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 5
79
 
 
01
02
03
04
05
06
07
08
09
10
Quando conseguimos definir claramente como será feita a interação entre os componentes de um sistema, ao utilizarmos os conceitos de Arquitetura de Sistemas, conseguimos gerar um ambiente mais assertivo no desenvolvimento destes sistemas.
Nesta aula então, apresentaremos como lidar comas interfaces de componentes e como estas nos auxiliam na complexa tarefa de modelagem de sistemas por componentes e a sua relação os resultados a serem alcançados. Desta maneira ficará evidente sua importância e sua aplicação no contexto da Arquitetura de Sistemas.
81
INTRODUÇÃO
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
82
A modelagem de interação de componentes é uma técnica de modelagem do comportamento dos componentes em relação ao problema a ser resolvido. Vamos usá-la aqui para definir as várias interações que precisam ocorrer dentro do sistema, para refinar as definições de interface existente, para identificar como as interfaces serão utilizadas, além de descobrir novas interfaces e operações.
Interação de Componentes
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
83
Fonte: O Autor
Identificação de Componentes
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
84
Neste momento o modelo de negócios é validado e as operações são representadas, de maneira que todas relações de funcionamento do negócio que o sistema proposto está se propondo a resolver, além de proporcionar o mapeamento das operações que este modelo de negócio representa.
Definir Operações de Negócios
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.
Fonte: msdn.microsoft.com
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
85
Refinar as regras de negócio, é o sub processo responsável por revistar o modelo de negócios, alterando e adaptando os elementos na medida das necessidades. Visto que agora temos as informações das operações de negócio mapeadas e definidas. 
Refinar Interfaces e Regras de Negócio
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
86
Fonte: O Autor
Refinar Interfaces e Regras de Negócio
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
87
Neste sub processo 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;
Refinar Definição de Componentes e Arquitetura
Fonte:O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
88
Neste contexto teremos os três sub processos desta aula (DEFINIR OPERAÇÕES DE NEGÓCIOS, REFINAR INTERFACES E REGRAS DE NEGÓCIO e REFINAR DEFINIÇÃO DE COMPONENTES E ARQUITETURA), servindo como mecanismos de garantia da qualidade e de assertividade no resultado do novo sistema a ser desenvolvido, dentro do contexto da Arquitetura de Sistemas.
Processos da Aula
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Vimos os conceitos de interação decomponentes dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na definição e de identificação de interfaces no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
89
Síntese da Aula
Continuação na interação de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
Próxima Aula
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Nesta aula vimos a importância da definição dos elementos de interface dos componentes e como estes propiciam uma visão ampla e assertiva na hora de modelarmos a integração entre os componentes. Mas do ponto de vista do Arquiteto de Sistemas, você acha que podemos associar os elementos de interação de componentes com a imagem a seguir? 
90
Atividade 6 (ppt)
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
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 6
91
 
 
01
02
03
04
05
06
07
08
09
10
Introdução
93
Quando conseguimos definir claramente como será feita a interação entre os componentes de um sistema, ao utilizarmos os conceitos de Arquitetura de Sistemas, conseguimos gerar um ambiente maisassertivo no desenvolvimento destes sistemas.
Nesta aula então, apresentaremos como lidar comas interfaces de componentes e como estas nos auxiliam na complexa tarefa de modelagem de sistemas por componentes e a sua relação os resultados a serem alcançados. Desta maneira ficará evidente sua importância e sua aplicação no contexto da Arquitetura de Sistemas.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
94
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, e que ao mesmo tempo resolva todos os problemas propostos, sem que este perceba a complexidade embutida na aplicação.
Complexidade de Sistemas
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
95
Do ponto de vista do arquiteto de sistemas: bancos de dados, servidores, clientes, filtros, um ou mais componentes, dentre outros, e a interação entre eles pode ocorrer através de chamadas de procedimentos, acesso a variáveis, uso de protocolos para acesso a clientes e servidores, bancos de dados, e outros eventos quaisquer.
Componentes de uma Arquitetura de Sistemas
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
96
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. 
Estas camadas estruturais são os pilares do desenvolvimento de sistemas por componentes.
Divisão Estrutural de Componentes
Fonte: O Autor
SDKs – integração com utilitários
Pode-se especializar os aplicativos
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Camadas como Elementos de Controle Interação de Componentes
97
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Exemplo de Sistema de Gerenciamento de Versão
98
Fonte: O Autor
Componentes utilizáveis e os que precisam ser desenvolvidos
Ou aqui, se o banco for distribuído
Se o ambiente fosse distribuído, haveria uma outra camada de comunicação aqui, se o banco for centralizado.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Vantagens e Desvantagens do Uso de Camadas
99
Vantagens:
	- Facilidade de compreensão;
	- Facilidade de manutenção;
	- Desenvolvimento independente;
	- Facilidade de Reutilização.
Desvantagens:
	- Duplicação de funcionalidade;
	- Dificuldades de estruturar um sistema através de camadas;
	- Violação da Estruturação.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Elementos da RUP (Rational Unified Process)
100
A arquitetura de sistemas e as decisões que definem como o sistema será utilizado. 
- Definir os elementos e suas interfaces de modo a estabelecer a estrutura do sistema;
- Estabelecer o comportamento associado entre estes elementos que compõe o sistema;
- Composição dos elementos e suas estruturas, comportamentais e agregações de subsistemas.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Elementos de Implementação que 
afetam a Arquitetura de Sistemas
101
Arquitetura de computador;
Sistema Operacional;
Banco de Dados; - PostrgreSQL é o melhor para georreferenciamento.
Protocolos de rede;
Linguagem de programação;
Ambiente de interface gráfica;
Bibliotecas de funções disponíveis;
Sistemas legados;
Necessidades de performance;
Portabilidade.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Papel do Arquiteto de Sistemas 
na Interação de Componentes
102
Conhecer o negócio e os requisitos das aplicações a serem desenvolvidas;
Conhecer os componentes disponíveis no ambiente e nos sistemas instalados;
Conhecer as tecnologias disponíveis para construção e arquitetura de sistemas;
Conhecer as metodologias de desenvolvimento adequadas ao sistema a ser desenvolvido.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Padrão de Arquitetura MVC (Model View Controler)
103
MODEL Define a semântica da aplicação e define seu comportamento;
VIEW  Define a apresentação visual da aplicação;
CONTROLLER  Gerencia a interação da apresentação visual do sistema (VIEW) com os comportamentos da aplicação (MODEL).
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Interação de Componentes com OAS 
(Arquitetura Orientada a Serviços)
104
Na arquitetura de sistemas orientadas a serviços, todas as funcionalidades do sistema devem ser disponibilizadas na forma de serviços. Estes serviços se conectam através de um barramento de serviços (ESB).
Neste barramento são disponibilizadas as interfaces na forma de web services que interagem com o repositório de dados.
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos os conceitos de interação de componentes dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na definição e de identificação de interfaces no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
105
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Próxima Aula
Especificação de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
106
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 7
107
Fonte: mundoeducacao.bol.uol.com.br
Nesta aula vimos a importância da definição dos elementos de interface dos componentes e como estes propiciam uma visão ampla e assertiva na hora de modelarmos a integração entre os componentes. Mas do ponto de vista do Arquiteto de Sistemas, você acha que podemos associar os elementos de interação de componentes com a imagem a seguir? 
 
 
01
02
03
04
05
06
07
08
09
10
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. Isto ocorre pois, nem sempre as informações repassadas pelos partes interessadas vão estar de acordo com as normas para desenvolvimento.
109
Apresentação da Aula
Aqui nós veremos um conjunto de ações necessárias para que a especificação consiga, de forma concreta, representar todas as informações levantadas de maneira consistente para os programadores. Faremos a apresentação do conceito de especificação como a tradução dos elementos de requisitos para elementos de programação.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Definição de Especificação de Componentes
110
Um componente tem uma especificação, pode ser distribuído, pode ser empacotado em módulos, deve ser aderente a padrões e tem uma implementação.
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
111
Os componentes mais importantes de um sistema a ser desenvolvido, baseado nos conceitos de arquitetura de sistemas, são: Objetos de sistemas prontos, Aplicativos da instalação, SGBD, Elementos de Sistema Operacional, Elementos de comunicação, Elementos de Hardware e os Componentes a serem desenvolvidos para o sistema. Aqui vamos nos ater a este último tipo.
Tipos de Componentes
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Especificação de Componentes a Serem Desenvolvidos
112
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Metodologias / Padrões
113
Fonte: O Autor (Baseado em padrões de projetos UML)
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Empacotamento de Componentes
114Fonte: www.dca.fee.unicamp.br
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Distribuição de Componentes
115
O arquiteto de sistemas, deve ter a preocupação de definir e construir middleware’s que conectem as diversas camadas de componentes, e consequentemente os componentes, de maneira a conseguir uma forte acoplagem para a organização.
Conectados corretamente, níveis corretos de suporte a configuração e os níveis de segurança corretos
Fonte: msdn.microsoft.com
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Implementação de Componentes
116
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Próxima Aula
Provisionamento e Construção de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
117
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos o conceito de requisitos dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na definição de requisitos no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
118
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 8
119
Nesta aula vimos a importância de especificação de componentes para o sucesso do desenvolvimento de sistemas de acordo com os conceitos da Arquitetura de Sistemas. Mas do ponto de vista do arquiteto, você acha que podemos associar a especificação de componentes a imagem a seguir? 
Fonte: o Autor
 
 
01
02
03
04
05
06
07
08
09
10
Introdução
121
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 solução do problema apresentados pelos partes interessadas e constante do sistema a ser desenvolvido.
Qual 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.
Apresentaremos a maneira que os programadores devem lidar com a construção de componentes, e a sua relação os resultados a serem alcançados na Arquitetura de Sistemas.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
COMPONENTES
122
Fonte: O Autor
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Ambiente de Componentes
123
Um ambiente componente é um meio ambiente de objetos distribuídos, estes 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.
Além disso, vamos nos limitar a esses ambientes de componentes que fornecem estes serviços de infraestrutura declarativa, usando uma abordagem por framework (por vezes chamado de "programação baseada em atributo"), em vez de usarmos uma invocação explícita dentro da própria lógica da aplicação.
Fazemos isso pois esses 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. Neste contexto, temos as seguintes opções:
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Framework CCM – Corba Component Model
124
O CCM é um framework de componentes do lado do servidor, cuja finalidade é facilitar o desenvolvimento e a instalação de aplicações distribuídas que utilizam a arquitetura de sistemas por componentes. Estes componentes podem ser dos diversos tipos já vistos.
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.
O CCM é também estruturado em cinco tipos de modelos:
Abstrato: Define atributos, portas de comunicação e home dos componentes;
de Programação: Composto por CIDL (Component Implementation Definition Language) e CIF (Framework);
de Empacotamento - Especifica como os componentes e suas implementações devem ser empacotados;
de Instalação - Define um mecanismo padrão para a instalação de aplicações;
de Execução - Define o ambiente de execução para as instâncias do componente.
Common Object Request Broker Architecture
Common Object Request Broker Architecture) é a arquitetura padrão criada pelo Object Management Group para estabelecer e simplificar a troca de dados entre sistemas distribuídos heterogêneos
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Arquivos CIDL
125
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Arquivos CIF (Component Implementation Framework)
126
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 Definition 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.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Containers
127
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. Para isso foram definidos os containers:
Ativação/desativação de implementações de componentes, preservando recursos;
Fornecimento de camada de adaptação com os serviços de transação, persistência, segurança e notificação;
Fornecimento de camada de adaptação para call-backs e 
Gerenciamento de políticas da POA.
O gerenciamento do ciclo de vida dos componentes de servidor é feito por meio de políticas que controlam o momento de ativação/desativação dos componentes:
Method: ativação/desativação a cada chamada de método, limitando o uso de memória ao tempo de duração da operação, mas acrescentando o custo de ativação e desativação do componente;
Transaction: ativação/desativação a cada transação. Memória permanece alocada durante a transação;
Component: o container ativa o componente quando for feita a primeira chamada a alguma de suas operações, e desativa quando explicitamente requisitado pela aplicação, desalocando a memória utilizada pelo componente;
Container: o componente será ativado quando for feita a primeira chamada a alguma de suas operações e, ao final da execução da mesma, será desativado. Entretanto, a memória permanecerá alocada até que o container decida deslocá-la;
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Empacotamento e Distribuição
128
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 Definition (DTD) definido pelo consórcio WWW. Componentes são empacotados em DLLs. Package descriptors são documentos XML em conformidade com o OSD 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 tem como objetivo o suporte à implantação automática dos componentes.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Próxima Aula
Continuação da construção de Componentes na Arquitetura de Sistemas;
Seu impacto no desenvolvimento de sistemas por componentes.
129
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Atividade 9
130
Nesta aula vimos a importância, para os Desenvolvedores, na construção de todos os componentes disponíveis e assim gerar o novo sistema com esta rica abordagem (componentes), para a Arquitetura de Sistemas. Do ponto de vista do Desenvolvedor, você acha que podemos associar a construção de componentes com a imagem a seguir? 
 
 
01
02
03
04
05
06
07
08
09
10
Síntese da Aula
Vimos o conceito de construção de componentes dentro da Arquitetura de Sistemas;
Apresentamos as boas práticas na construção de componentes no desenvolvimento de Sistemas;
Analisamos seus resultados e como estes resultados podem melhorar o resultado dos projetos.
131
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Introdução
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 solução do problema apresentado pelos partes interessadas e constante do sistema a ser desenvolvido.
Nesta aula então, apresentaremos a maneira que os programadores devem lidar com a construção de componentes, e a sua relação os resultados a serem alcançados. Desta maneira ficará evidente sua importância de sua aplicação no contexto da Arquitetura de Sistemas.
133
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Especificação de Componentes x 
Construção de Componentes
134
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 têm uma correspondência bastante simples entre os elementos de especificação os elementos de execução.
UML também define a relação entre o componente e uma interface através de relacionamentos.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Mapeamento e Construção de Restrições
135
Os principais problemas com mapeamento de construção e restrições com componentes de tecnologia surgem a partir das seguintes considerações:
Tipo de parâmetro Operação, tipo (in / out / inout / volta), e de referência das restrições;
Mecanismos de manipulação de exceção e de erro;
Restrições herança de interface e suporte;
Sequências de operação;
Propriedades de Interface;
Mecanismos de criação do objeto;
Disponibilizar eventos.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Herança de Interfaces e Suporte de Interfaces
136
Há uma diferença enorme entre o COM + e EJB quando se trata de herança de interface e suporte de interfaces.
COM + permite apenas herança única de interface. Para permitir que objetos tenham múltiplas classificações, os componentes devem suportar múltiplas interfaces.
Por ex., um objeto documento COM +, suportando IDocument, IInvoice e lAccStmnt pode ser:
 um documento,
 uma fatura ou 
um extrato de conta. 
* todas as interfaces COM + devem finalmente herdar de IUnknown-a, interface base COM +.
EJB permite herança múltipla de interfaces e permite que classes Java apoiem múltiplas interfaces, limitando apenas unicamente herança de classe.
Quando registramos uma classe Java como um EJB com um ambiente de componentes EJB, ficamos restritos a nomeação de uma interface (a chamada interface remota).
O container para o seu EJB fornece uma classe de suporte para essa interface, que são, então, delegados a sua classe Java.
Apesar de sua classe Java poder suportar muitas interfaces, o container EJB fica limitado a somente um deles.
Isso significa que se você quiser que seu componente suporte múltiplas interfaces você vai precisar usar herança de interface múltipla para herdar toda a funcionalidade do componente de uma interface pai, que pode ser registrada no ambiente EJB. Esta super interface é utilizada efetivamente durante a especificação do componente.
Devemos tomar cuidado ao usar a herança com tipos de interface. Sabendo-se que esses são artefatos de especificação, de definição e de herança, eles vão se comportar de formas diferentes.
Ao contrário de herança de classe de implementação (onde métodos de subclasse podem substituir os métodos da superclasse), as especificações de operação de subtipos só podem incrementar as definições por seus supertipos.
Mais especificamente, isso significa que uma especialização de operações pode enfraquecer uma condição prévia (torná-la menos rigorosa) e fortalecer a pós-condição (torná-la mais rigorosa).
Isso assegura que qualquer cliente, dependente dos pressupostos e garantias do supertipo, não vai encontrar o subtipo se comportando de forma inesperada.
EJB: Chamada remota precisa de herança múltipla
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Propriedades de Interfaces
137
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 você deseja. Por exemplo, a interface base COM + IUnknown tem duas operações para o gerenciamento de contagens de referência:
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.
Assim, para mapeamento para COM +, precisamos de uma maneira para determinar quais as operações devemos mapear para a propriedade COM + taquigrafia. 
Uma forma simples é usar uma convenção de nomenclatura.
Alternativamente, poderíamos fazer um trabalho mais elaborado e estender a especificação da operação com um valor pré-definido para o nome da propriedade, e interpretar a partir da existência dentro dos parâmetros para determinar qual foi o get e que foi o conjunto de informações adquiridas.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Criação de Objetos
138
Tanto no EJB como no COM + usamos uma abordagem de fábrica de objetos, onde um objeto componente é usado para criar instâncias de outro componente. 
	No EJB a fábrica é o objeto inicial, no COM + é objeto IClassFactory.
Dentro dos diagramas de arquitetura de componentes e interações de componentes achamos melhor conveniente para omitir este nível de abstração e simplesmente mostram << criar >> dependências diretamente para o próprio componente.
No COM +, há muita flexibilidade sobre qual objeto é a fábrica. Isto é feito simplesmente designando um componente que disponibiliza o IClassFactory relevante para uma dada classe. 
Este mesmo elemento também pode fazer outras coisas, e neste caso, você deve disponibilizar uma funcionalidade para o mesmo.
Atenção
Para beans de sessão EJB, você precisa apenas fornecer uma especificação da interface inicial, mas, para beans de entidade, você precisa fornecer a implementação também.
01
02
03
04
05
06
07
08
09
10
 
01
02
03
04
05
06
07
08
09
10
Correspondência da Arquitetura da Aplicação
139
Apresentamos aqui uma série de camadas distintas na arquitetura de aplicação, onde cada camada contem diferentes responsabilidades.