Aulas Arquiteturas Sistemas (naocompleto)

Prévia do material em texto

ARQUITETURA DE SISTEMAS
Prof. Alessandro Larangeiras
CONTEÚDO
1. ARQUITETURA DE SISTEMAS
1.1 Componentes de sistemas
1.1.1 Fundamentos e objetivos
1.1.2 Uso de componentes
1.2 Definição da arquitetura de sistemas e componentes
1.3 Camadas da arquitetura de sistemas
1.4 Arquitetura de componentes
1.5 Modelagem
1.5.1 Níveis de modelo
1.5.2 Categorias de modelos
2 / 67
CONTEÚDO (cont.)
2. PROCESSO DE DESENVOLVIMENTO
2.1 Gerenciamento de processos
2.2 Objetivos das metodologias de desenvolvimento e gestão
2.3 Especificação de componentes
2.4 Interação entre componentes
2.5 Aplicação da UML
2.5.1 Uso da UML na arquitetura de sistemas
2.5.2 Técnicas de modelagem
2.5.3 Tipos de modelo
2.5.4 Especificação de interface
3. REQUISITOS
3.1 Definição de requisitos
3.2 Tipos de requisitos
3.3 Técnicas de levantamento de requisitos
3.4 Validação de requisitos
3.5 Prototipação
3.6 Modelagem conceitual de negócios e de sistemas
3 / 67
CONTEÚDO (cont.)
4. COMPONENTIZAÇÃO
4.1 Identificação dos componentes
4.2 Modelagem dos artefatos do sistema
4.2.1 Modelo de negócios
4.2.2 Interface de negócios
4.2.3 Interface de sistemas
4.3 Interação de componentes
4.3.1 Definição das operações de negócio
4.3.2 Refinamento dos artefatos do sistema
4.3.3 Divisão em camadas
4.3.4 Rational Unified Process (RUP)
4.3.5 Model-View-Controller (MVC)
4.3.6 Arquitetura Orientada a Serviços (AOS)
4.4 Especificação de componentes
4.4.1 Tipos de componentes
4.4.2 Metodologias e padrões
4.4.3 Implementação, empacotamento e distribuição
4 / 67
CONTEÚDO (cont.)
5. PROVISIONAMENTO E CONSTRUÇÃO
5.1 Framework CCM (Corba Component Model)
5.2 Especificação vs. construção
5.3 Interfaces
5.3.1 Propriedades
5.3.2 Herança e suporte
5.4 Interação com sistemas existentes e legados
5.5 Construção
5 / 67
CONTEÚDO (cont.)
6. TÓPICOS EM ARQUITETURA DE SISTEMAS
6.1 Arquitetura Monolítica
6.2 Arquitetura de Microsserviços
6.2.1 Monolítica vs. Microsserviços
6.2.2 Componentização por serviços
6.2.3 Descentralização
6.2.4 Desafios da implementação
6.3 Virtualização
6.3.1 Infraestrutura como serviço
6.3.2 Tecnologia de virtualização
6.3.3 Software de virtualização
6.4 Containers
6.4.1 O que são textitcontainers
6.4.2 Containers vs. máquinas virtuais
6.4.3 Os containers Docker
6.4.4 Criação e gerenciamento de imagens
6 / 67
BIBLIOGRAFIA PRINCIPAL
GALLOTTI, Giocondo M. A. (Org.). Arquitetura de
Software. São Paulo: Pearson, 2017.
SOMMERVILLE, Ian. Engenharia de Software. 10ed. Rio
de Janeiro: Pearson, 2019.
7 / 67
OUTRAS FONTES
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software
Architecture in Practice. 3rd ed. Boston: Addison-Wesley,
2013.
URL: <https://www.sei.cmu.edu/>.
ISO/IEC/IEEE 42010/2011: Systems and Software
Engineering – Architecture Description, recomendações
para descrição da arquitetura de sistemas intensivos de
software.
URL:
<http://www.iso-architecture.org/ieee-1471/index.html>.
8 / 67
https://www.sei.cmu.edu/
http://www.iso-architecture.org/ieee-1471/index.html
CONTEÚDO
1. ARQUITETURA DE SISTEMAS
1.1 Componentes de sistemas
1.1.1 Fundamentos e objetivos
1.1.2 Uso de componentes
1.2 Definição da arquitetura de sistemas e componentes
1.3 Camadas da arquitetura de sistemas
1.4 Arquitetura de componentes
1.5 Modelagem
1.5.1 Níveis de modelo
1.5.2 Categorias de modelos
9 / 67
1.1 CONCEITOS PRELIMINARES
10 / 67
CONCEITOS
«Algoritmo é a especificação da seqüência ordenada de
passos que deve ser seguida para a solução de um
problema ou para a realização de uma tarefa, garantindo
a sua repetibilidade.» (MALAQUIAS, 2011, slide 3).
11 / 67
CONCEITOS (cont.)
«[...] [Programa de computador é] a expressão de um conjunto
organizado de instruções em linguagem [...] codificada
[(algoritmos)], contida em suporte físico de qualquer natureza, de
emprego necessário em máquinas automáticas de tratamento da
informação, dispositivos, instrumentos ou equipamentos
periféricos [...], para fazê-los funcionar de modo e para fins
determinados.» (BRASIL, 1998, grifo nosso).
12 / 67
CONCEITOS (cont.)
Unidade de programa é
um segmento do
programa, contendo
algoritmos
inter-relacionados (BRASIL,
1998; MALAQUIAS, 2011, slide 3;
SOMMERVILLE, 2007, p. 67).
Unidade de programa:
classe Java (direita).
13 / 67
CONCEITOS (cont.)
Software é a parte lógica de um sistema, na forma de um
programa de computador e, eventualmente, de sua
documentação integrante e dos dados de configuração
necessários para o seu correto funcionamento (FRIEDMAN; TRAN;
GODDARD, 1992, p. 1; SALEH, 2009, p. 2; SOFTWARE, 2020; SOMMERVILLE, 2007, p.
5).
14 / 67
CONCEITOS (cont.)
«Sistema é um conjunto interconectado de máquinas, aplicações
[(softwares)] e recursos de rede [...].» (MCGOVERN et al., 2004, p. 1,
tradução nossa).
Item de sistema é um segmento do sistema, na forma de um
software, um hardware ou um recurso de rede (GONZÁLES-PÉREZ;
HENDERSON-SELLERS, 2006, p. 137-138).
«[Sistemas intensivos de software (software-intensive systems)
são] sistemas cujo software interage com outros softwares,
sistemas, dispositivos, sensores e pessoas [...].» (WIRSING; HOLZL,
2006, p. 2, tradução nossa).
15 / 67
CONCEITOS (cont.)
Sistema.
16 / 67
CONCEITOS (cont.)
Design Patterns (Padrões de Projeto) são estratégias
convencionais para organizar ALGORITMOS do sistema
(composição).
Architecture Patterns (Padrões Arquiteturais) e Architecture
Styles (Estilos Arquiteturais) são estratégias convencionais para
organizar INFRAESTRUTURAS do sistema (distribuição).
17 / 67
CONCEITOS (cont.)
Algoritmos (acima).
Unidades de programa distribuídas
em uma infraestrutura (direita).
18 / 67
MAPA CONCEITUAL
Conceitos de Engenharia de Software.
19 / 67
1.2 ARQUITETURA DE SISTEMAS E COMPONENTES
20 / 67
ARQUITETURA DE SOFTWARE
Arquitetura de software (software architecture) é a constituição
de um sistema, na forma de seus elementos e contextos, e os
princípios que guiam o seu projeto, construção e evolução (IEEE
1471, 2000 apud EELES; CRIPPS, 2010, p. 9).
21 / 67
ARQUITETURA DE SOFTWARE (cont.)
«[...] Todo sistema de computação com software tem uma arquitetura de
software, porque todo sistema pode conter elementos e as relações
entre eles. No caso mais comum, um sistema é em si um único
elemento – desinteressante e provavelmente não muito útil, mas, ainda
assim, uma arquitetura. Apesar de todo sistema ter uma arquitetura, isto
não indica necessariamente que seja conhecida por alguém. É possível
que todos aqueles que projetaram o sistema estejam longe, a
documentação tenha desaparecido (ou nunca sido produzida), o
código-fonte tenha se perdido (ou nunca sido entregue) e só nos reste
um código binário executável. Isto revela a diferença entre a arquitetura
de um sistema e a representação desta arquitetura. Infelizmente, uma
arquitetura pode existir independentemente da sua descrição ou
especificação, o que aumenta a importância da documentação
arquitetural [...] e da reconstituição arquitetural [(architecture
reconstruction)] [...].» (BASS; CLEMENTS; KAZMAN, 2003, p. 21, tradução nossa).
22 / 67
ARQUITETURA VS. DESIGN
«A arquitetura de software de um programa ou sistema de computação é
a estrutura ou estruturas do sistema, que incluem os elementos de
software, as propriedades externamente visíveis destes elementos e os
relacionamentos entre ambos. [...] Em quase todos os sistemas
modernos, os elementos interagem entre si por meio de interfaces, que
particionam os detalhes de um elemento em partes públicas e privadas.
A arquitetura está preocupada com o lado público desta divisão; os
detalhes privados – aqueles unicamente relacionados à implementação
interna – não são arquiteturais.» (BASS; CLEMENTS; KAZMAN, 2003, p. 3/21,
tradução nossa).
«Toda arquitetura é design, mas nem todo design é arquitetura. A
arquitetura se concentra nas decisões de design significantes, aquelas
que são estrutural e comportamentalmente importantes e têm impacto
duradouro no desempenho, confiabilidade, custo e resiliência do
sistema. A arquiteturaenvolve o "como"e o "por que", não só "o que".»
(BOOCH, 2006, slide 31, tradução nossa).
23 / 67
ARQUITETURA VS. DESIGN (cont.)
«Os requisitos se preocupam com a determinação da
informação, do processamento e as características de ambos,
necessários ao usuário do sistema. A arquitetura se preocupa
com a seleção dos elementos arquiteturais, suas interações e as
restrições de ambos, necessárias à produção de uma prescrição
que satisfaça os requisitos e sirva de base para o design. O
design se preocupa com a modularização e o detalhamento das
interfaces dos elementos, seus algoritmos e procedimentos, e os
tipos de dados necessários ao suporte da arquitetura e à
satisfação dos requisitos. [...] A implementação se preocupa com
as representações dos algoritmos e tipos de dados que satisfazem
o design, a arquitetura e os requisitos.» (PERRY; WOLF, 1992, p. 43,
tradução e grifo nossos).
24 / 67
ARQUITETURA DE SISTEMA
«Sistema é um conjunto interconectado de máquinas, aplicações
e recursos de rede. A Arquitetura de sistemas [(systems
architecture)] unifica esse conjunto, impondo estrutura ao
sistema. E o mais importante, esta estrutura alinha as
funcionalidades do sistema às metas do negócio.» (MCGOVERN et al.,
2004, p. 1, tradução e grifo nossos).
25 / 67
ELEMENTOS ARQUITETURAIS
Elementos (elements ou architectural elements) são entidades
ou peças arquiteturalmente significantes, empregadas na
construção de sistemas (ROZANSKI; WOODS, 2012, p. 12/20).
26 / 67
ELEMENTOS ARQUITETURAIS (cont.)
Os elementos arquiteturais se dividem em três categorias:
i. elementos de software: proveem o necessário para o
processamento dos elementos de dados (PERRY; WOLF, 1992, p.
44). Por exemplo, classes, objetos, pacotes, subsistemas etc.
(BARBOSA, 2009, p. 90; BASS; CLEMENTS; KAZMAN, 2013, p. 332/335; OBJECT
MANAGEMENT GROUP, 2011, p. 704; ROZANSKI; WOODS, 2012, p. 12).
27 / 67
ELEMENTOS ARQUITETURAIS (cont.)
ii. elementos de dados: contêm a informação que é usada
(PERRY; WOLF, 1992, p. 44). Por exemplo, classes de dados,
repositórios de dados, arquivos de dados etc. (BARBOSA, 2009, p.
90; BASS; CLEMENTS; KAZMAN, 2013, p. 335).
iii. elementos de hardware: conectam os elementos de
software e de dados entre si e ao ambiente físico (GUBBI et al.,
2013, p. 1645; PERRY; WOLF, 1992, p. 44). Por exemplo, clientes,
servidores, periféricos, dispositivos de rede etc. (BARBOSA, 2009,
p. 90; BASS; CLEMENTS; KAZMAN, 2013, p. 335; ROZANSKI; WOODS, 2012, p.
13).
28 / 67
MÓDULOS E COMPONENTES E CONECTORES
Elementos arquiteturais manifestam-se como estruturas estáticas
(static structures) ou estruturas dinâmicas (dynamic structures)
(ROZANSKI; WOODS, 2012, p. 12/20).
As estruturas estáticas, ou módulos (modules), são os
elementos arquiteturais (de software, de dados e de hardware),
bem como seus atributos e relacionamentos, examinados fixos no
tempo, inertes, em design time (LATTANZE, 2008, p. 51; QIAN; GERO, 1996,
p. 293; ROZANSKI; WOODS, 2012, p. 12).
As estruturas dinâmicas, ou componentes e conectores
(components-and-connectors), são os elementos arquiteturais
(de software, de dados e de hardware), seus atributos e
relacionamentos, examinados móveis no tempo, ativos, em
compile time e/ou runtime (LATTANZE, 2008, p. 52; QIAN; GERO, 1996, p.
293; ROZANSKI; WOODS, 2012, p. 13).
29 / 67
MÓDULOS E COMPONENTES E CONECTORES (cont.)
Módulos arquiteturalmente significantes são retratados em UML
por meio de diagramas de pacotes.
Fonte: Adaptado de MERSON; SAINI, 2019.
30 / 67
MÓDULOS E COMPONENTES E CONECTORES (cont.)
Componentes e conectores são retratados em UML por meio de
diagramas de componentes.
31 / 67
1.3 CAMADAS DA ARQUITETURA DE SISTEMAS
32 / 67
ESTILOS E PADRÕES ARQUITETURAIS
Estilo arquitetural (architectural style) é um modelo
convencional que caracteriza um perfil de arquitetura de software,
DESCREVENDO sua organização estrutural (topologia [topology])
e seu contexto de aplicação (AVGERIOU; ZDUN, 2005, p. 2; CLEMENTS et al.,
2011, p. 33-34/36; EELES; CRIPPS, 2010, p. 95; MEHTA; MEDVIDOVIC, 2003, p. 347;
MONROE et al., 1997, p. 45; ROZANSKI; WOODS, 2012, p. 164/169).
Padrão arquitetural (architectural pattern) é um modelo
convencional que caracteriza um perfil de arquitetura de software,
PRESCREVENDO sua organização estrutural (topologia
[topology]) e seu contexto de aplicação (AVGERIOU; ZDUN, 2005, p. 2;
CLEMENTS et al., 2011, p. 33-34). Cada padrão arquitetural instrui
minuciosa e imperativamente o processo de design, de modo a
garantir a repetibilidade da solução (CLEMENTS et al., 2011, p. 33-34).
33 / 67
ESTILOS ARQUITETURAIS MAIS COMUNS
i. estilo arquitetural em camadas (layered architectural
style);
34 / 67
ESTILOS ARQUITETURAIS MAIS COMUNS (cont.)
ii. estilo arquitetural baseado em componentes
(component-based architectural style).
35 / 67
RESUMINDO...
«Software Architecture = { Elements, Form, Rationale }»
(PERRY; WOLF, 1992, p. 44).
36 / 67
MODELO CONCEITUAL
Modelo conceitual de descrição arquitetural, conforme o padrão
ISO/IEC/IEEE 42010.
Fonte: <http://www.iso-architecture.org/ieee-1471/cm/>, acesso em 27 jul. 2020.
37 / 67
http://www.iso-architecture.org/ieee-1471/cm/
LEITURA RECOMENDADA
MONROE, Robert T.; KOMPANEK, Drew;
MELTON, Ralph; GARLAN, David.
Architectural Styles, Design Patterns,
and Objects. IEEE Software, v. 14, n. 1, p.
43-52, Jan./Feb. 1997.
38 / 67
ATIVIDADE
Faça a leitura recomendada e, a partir dela, um RESUMO de dois
parágrafos, realçando as seguintes questões:
i. Em sua opinião, como o projeto arquitetural pode guiar o
processo de desenvolvimento de um sistema?
ii. Em sua opinião, qual é o benefício mais significante que a
adoção de um estilo ou padrão arquitetural pode conferir ao
processo de desenvolvimento de um sistema?
39 / 67
1.4 ARQUITETURA DE COMPONENTES
40 / 67
COMPONENTES: FUNDAMENTOS E USO
Componentes (components) são peças compartimentais,
componíveis e substituíveis, que se manifestam em compile time
e/ou runtime e representam o aspecto estrutural dinâmico do
sistema: funcionalidade, processamento, manutenção de estado
(manipulação de dados) e concorrência (BARBOSA, 2009, p. 90; BASS;
CLEMENTS; KAZMAN, 2013, p. 13; OBJECT MANAGEMENT GROUP, 2011, p. 149;
ROZANSKI; WOODS, 2012, p. 13).
Um componente deve ser:
X padronizado: se conformar a um modelo que estabeleça suas
interfaces, metadados, documentação, e regras de
composição e implantação;
X independente: garantir composição e implantação livre da
dependência de outros componentes, o máximo possível;
41 / 67
COMPONENTES: FUNDAMENTOS E USO (cont.)
X componível: possibilitar que todas as interações externas
ocorram por meio de interfaces publicamente definidas e
prover um modo de acesso às suas informações internas
(atributos e métodos);
X implantável: apresentar autossuficiência e disponibilidade
(não necessitar de compilação para ser implantado);
X documentado: possuir documentação sintática e,
preferencialmente, semântica de todas as suas interfaces,
possibilitando aos usuários em potencial determinar se
atende às suas necessidades.
(SOMMERVILLE, 2007, p. 443).
42 / 67
COMPONENTES: FUNDAMENTOS E USO (cont.)
A técnica de dividir para conquistar (divide and conquer)
propõe a solução de um problema por meio da sua decomposição
recursiva: o problema é dividido em subproblemas do mesmo tipo,
cada subproblema é resolvido independentemente e as subsolu-
ções encontradas são combinadas para compor a solução do pro-
blema original (CUNNINGHAM; LIU; ZHANG, 2004, p. 2; SHAN; HUA, 2009, p. 5).
«Um princípio da engenharia de software há muito estabelecido é
a separação da descrição de "o quê" uma unidade de software faz
(por exemplo, "especificação", "interface" e "assinatura") da
descrição de "como" ela o faz (por exemplo, "realização", "design",
"arquitetura", "corpo" e "implementação"). Esta separação facilita
a adoção da abordagem dividir para conquistar na modelagem,
na qual a unidade de software pode ser desenvolvida independen-
temente.Isto permite também que versões antigas de uma
unidade sejam trocadas por novas versões, desde que façam a
mesma coisa.» (ATKINSON et al., 2015, tradução e grifo nossos).
43 / 67
COMPONENTES: FUNDAMENTOS E USO (cont.)
«Reuso de software é o uso de componentes de software
preexistentes para se construir novos sistemas. O reuso se aplica
não somente a fragmentos de código-fonte, mas a todos os
produtos de trabalho intermediários gerados durante o
desenvolvimento do software, incluindo documentos de requisitos,
especificações do sistema, estruturas de design e qualquer
informação que o desenvolvedor necessite para criar o software.»
(PRIETO-DÍAZ, 1993, p. 61, tradução e grifo nossos).
44 / 67
ENGENHARIA DE SOFTWARE BASEADA EM
COMPONENTES
«A Engenharia de Software Baseada em Componentes é uma
abordagem que considera a preexistência de uma quantidade
significativa de componentes reutilizáveis e propõe um processo
de desenvolvimento concentrado na interação destes componen-
tes em vez de desenvolvê-los do zero.» (SOMMERVILLE, 2007, p. 65,
tradução e grifo nossos).
DBC – Desenvolvimento
Baseado em Componentes
(GEROSA; STEINMACHER,
2012, p. 364).
45 / 67
ENGENHARIA DE SOFTWARE BASEADA EM
COMPONENTES (cont.)
«Na maioria dos projetos de software, há algum nível de reuso.
Em geral, isto ocorre informalmente, quando as pessoas que
trabalham no projeto sabem quais designs ou códigos existentes
são similares ao requisitado [...]. Este reuso informal independe do
processo de desenvolvimento adotado. [...] [Contudo, por ser
orientada ao reuso,] a engenharia de software baseada em
componentes tem a óbvia vantagem de reduzir a quantidade de
software a ser desenvolvido e, consequentemente, o custo e os
riscos, além de favorecer entregas mais rápidas [...].»
(SOMMERVILLE, 2007, p. 69-70, tradução nossa).
46 / 67
ARQUITETURA DE COMPONENTES
«Arquitetura de componentes é uma arquitetura baseada em
[...] componentes independentes, substituíveis e modulares, [...]
[que] auxilia a gerenciar a complexidade e encoraja o reuso.» (IBM,
2020, tradução e grifo nossos).
«Benefícios:
• Reusabilidade dos componentes.
• Manutenção e evolução do sistema; facilidade de modificar e
atualizar a implementação sem afetar o restante do sistema.
• Independência e flexiblidade na conectividade dos
componentes.
• Desenvolvimento independente dos componentes, por
diferentes grupos e em paralelo.
• Produtividade no desenvolvimento do software atual e futuro.
47 / 67
ARQUITETURA DE COMPONENTES (cont.)
• Muitas das ferramentas de design orientado a objetos
também podem ser utilizadas no desenvolvimento de
software baseado em componentes.
Limitações:
• Pode ser difícil encontrar componentes adequados
disponíveis para reuso.
• A adaptação dos componentes é uma preocupação.
• Há poucas ferramentas dedicadas ao design orientado a
componentes disponíveis.»
(QIAN et al., 2010, p. 260-261, tradução nossa).
48 / 67
1.5 MODELAGEM
49 / 67
MODELOS DE COMPONENTES
«Modelo de componente é uma definição dos padrões de
implementação, documentação e implantação de componentes,
para que desenvolvedores garantam a sua interoperação e
provedores de infraestrutura forneçam suporte à sua execução.»
(SOMMERVILLE, 2007, p. 445, tradução e grifo nossos).
Elementos básicos de um modelo de componentes
(SOMMERVILLE, 2007, p. 446).
50 / 67
MODELOS DE COMPONENTES (cont.)
«Atualmente, os modelos de componentes podem ser divididos
em duas categorias amplas: (i) modelos em que os componentes
são objetos, tal como na programação orientada a objetos; (ii)
modelos em que os componentes são unidades arquiteturais, tal
como em arquiteturas de software.» (LAU; TAWEEL, 2007, p. 1, tradução
nossa).
Exemplos da primeira categoria são o EJB – Enterprise
JavaBeans, concebido pela Sun Microsystems e mantido pela
Oracle, e o COM+ – Component Object Model Plus, concebido
pela Microsoft (SOMMERVILLE, 2007, p. 445).
Exemplos da segunda categoria são o CORBA – Common Object
Request Broker Architecture, concebido pelo OMG – Object
Management Group e as ADL – Architecture Description
Languages (LAU; TAWEEL, 2007, p. 1; SOMMERVILLE, 2007, p. 445).
51 / 67
MODELAGEM DE COMPONENTES
«Superficialmente, a engenharia de software baseada em
componentes se parece muito com a engenharia de software
tradicional, ou orientada a objetos. O processo se inicia quando
uma equipe de desenvolvimento estabelece os requisitos do
sistema, utilizando técnicas convencionais de elicitação de
requisitos. Um design arquitetural é estabelecido, mas, em vez de
seguir imediatamente para tarefas de design mais detalhadas, a
equipe examina os requisitos, para determinar qual subconjunto é
diretamente elegível para composição e não construção [...].
52 / 67
MODELAGEM DE COMPONENTES (cont.)
A equipe então tenta modificar ou remover aqueles requisitos de
sistema que não podem ser atendidos com componentes à venda
ou já desenvolvidos internamente. Se os requisitos não puderem
ser modificados ou excluídos, métodos de engenharia de software
tradicional, ou orientada a objetos, são aplicados para desenvolver
os novos componentes necessários. Mas, para os requisitos
atendidos com os componentes disponíveis, um conjunto diferente
de atividades de engenharia de software se inicia: Qualificação de
Componente, Adaptação de Componente, Composição de
Componente e Atualização de Componente [...].» (BOSE, 2010, p. 5,
tradução nossa).
53 / 67
LEITURA RECOMENDADA
PRIETO-DÍAZ, Rubén. Status Report:
Software Reusability. IEEE Software, v.
10, n. 3, p. 61–66, 1993.
54 / 67
ATIVIDADE
Faça a leitura recomendada e, a partir dela, um RESUMO de dois
parágrafos, realçando as seguintes questões:
i. Em sua opinião, como o reuso de ideias pode contribuir para
o projeto arquitetural de um sistema?
ii. Em sua opinião, qual dos termos da taxonomia de reuso tem
maior relevância para o desenvolvimento de um sistema
baseado em componentes?
55 / 67
56 / 67
57 / 67
"Treine enquanto eles dormem,
estude enquanto eles se divertem,
persista enquanto eles descansam
e então viva o que eles sonham."
– Muhammad Ali.
REFERÊNCIAS
ATKINSON, Colin; BUNSE, Christian; KAMSTIES,
Erik; ZETTEL, Jörg. Principles of UML-based Component
Modeling. In: . The Development of Component-
based Information Systems: Advances in Management
Information Systems. New York: Routledge, 2015. v. 2, cap. 4.
AVGERIOU, Paris; ZDUN, Uwe. Architectural Patterns
Revisited: A Pattern Language. In: Tenth European Conference
on Pattern Languages of Programs (EuroPLoP’05). Irsee, 2005.
p. 1–39.
BARBOSA, Guilherme M. G. Um Livro-texto para o Ensino
de Projeto de Arquitetura de Software. 209 f. Dissertação
(Mestrado em Ciência da Computação) — Universidade Federal
de Campina Grande, Curso de Pós-Graduação em Ciência da
Computação, Campina Grande, 2009.
58 / 67
REFERÊNCIAS (cont.)
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software
Architecture in Practice. 2nd. ed. Boston: Addison-Wesley,
2003.
BASS, Len; CLEMENTS, Paul; KAZMAN, Rick. Software
Architecture in Practice. 3rd. ed. Boston: Addison-Wesley,
2013.
BOOCH, Grady. Handbook of Software Architecture.
2006. 98 slides: color. Disponível em: <http://paginas.fe.up.
pt/~aaguiar/as/AS-200506-Software_Architecture_by_Booch.
pdf>. Acesso em: 07 out. 2014.
BOSE, Debayan. Component Based Development:
Application in Software Engineering. CoRR, p. 1–25, 2010.
Disponível em: <https://arxiv.org/pdf/1011.2163.pdf>. Acesso
em: 17 ago. 2020.
59 / 67
http://paginas.fe.up.pt/~aaguiar/as/AS-200506-Software_Architecture_by_Booch.pdf
http://paginas.fe.up.pt/~aaguiar/as/AS-200506-Software_Architecture_by_Booch.pdf
http://paginas.fe.up.pt/~aaguiar/as/AS-200506-Software_Architecture_by_Booch.pdf
https://arxiv.org/pdf/1011.2163.pdf
REFERÊNCIAS (cont.)
BRASIL. Lei no 9.609, de 19 de fevereiro de 1998, dispõe
sobre a proteção da propriedade intelectual de programa
de computador, sua comercialização no país, e dá outras
providências. Diário Oficial da União, Brasília, 1998.
Disponívelem: <http://www.planalto.gov.br/ccivil_03/leis/l9609.
htm>. Acesso em: 22 jul. 2020.
CLEMENTS, Paul; BACHMANN, Felix; BASS, Len;
GARLAN, David; IVERS, James; LITTLE, Reed; MERSON,
Paulo; NORD, Robert; STAFFORD, Judith. Documenting
Software Architectures: Views and Beyond. 2nd. ed. Boston:
Addison-Wesley, 2011.
CUNNINGHAM, H. Conrad; LIU, Yi; ZHANG, Cuihua. Using
the Divide and Conquer Strategy to Teach Java Framework
Design. In: Proceedings of the 3rd international Symposium
on Principles and Practice of Programming in Java. 2004.
p. 40–45. Disponível em: <https://john.cs.olemiss.edu/~hcc/
papers/divConq.pdf>. Acesso em: 15 ago. 2020.
60 / 67
http://www.planalto.gov.br/ccivil_03/leis/l9609.htm
http://www.planalto.gov.br/ccivil_03/leis/l9609.htm
https://john.cs.olemiss.edu/~hcc/papers/divConq.pdf
https://john.cs.olemiss.edu/~hcc/papers/divConq.pdf
REFERÊNCIAS (cont.)
EELES, Peter; CRIPPS, Peter. The Process of Software
Architecting. Massachusetts: Addison-Wesley, 2010.
FRIEDMAN, Michael A.; TRAN, P. Y.; GODDARD,
Peter L. Reliability Techniques for Combined Hardware
and Software Systems. Technical Report RL-TR-92-15.
Rome Laboratory, New York, p. 1-275, 1992. Disponível em:
<http://www.dtic.mil/dtic/tr/fulltext/u2/a256347.pdf>. Acesso em:
05 jul. 2015.
GEROSA, Marco Aurélio; STEINMACHER, Igor.
Componentes de Software para Sistemas Colaborativos. In:
. Sistemas Colaborativos. Rio de Janeiro: Elsevier, 2012.
cap. 22, p. 363–375.
GONZÁLES-PÉREZ, César; HENDERSON-SELLERS,
Brian. An Ontology for Software Development Methodologies
and Endeavours. In: . Ontologies for Software
Engineering and Software Technology. Heidelberg: Springer,
2006. cap. 4, p. 123–151.
61 / 67
http://www.dtic.mil/dtic/tr/fulltext/u2/a256347.pdf
REFERÊNCIAS (cont.)
GUBBI, Jayavardhana; BUYYA, Rajkumar; MARUSIC,
Slaven; PALANISWAMI, Marimuthu. Internet of Things (IoT): A
Vision, Architectural Elements, and Future Directions. Future
Generation Computer Systems, v. 29, n. 7, p. 1645–1660,
2013.
IBM – INTERNATIONAL BUSINESS MACHINES. RUP –
Rational Unified Process: Component Architectures. [S.l.],
2020. Disponível em: <https://cgrw01.cgr.go.cr/rup/RUP/
SmallProjects/core.base_rup/guidances/supportingmaterials/
use_component_architectures_CBC2F6B5.html>. Acesso em:
15 ago. 2020.
LATTANZE, Anthony J. Architecting Software Intensive
Systems: A Practitioner’s Guide. Boca Raton: CRC Press,
2008.
62 / 67
https://cgrw01.cgr.go.cr/rup/RUP/SmallProjects/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
https://cgrw01.cgr.go.cr/rup/RUP/SmallProjects/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
https://cgrw01.cgr.go.cr/rup/RUP/SmallProjects/core.base_rup/guidances/supportingmaterials/use_component_architectures_CBC2F6B5.html
REFERÊNCIAS (cont.)
LAU, Kung-Kiu; TAWEEL, Faris M. Data Encapsulation in
Software Components. In: Proceedings of the 10th International
ACM SIGSOFT Symposium on Component-Based Software
Engineering (CBSE’07). Medford: ACM, 2007. p. 1–16.
MALAQUIAS, José R. Algoritmos: Conceito e
Representação. 2011. 30 slides: color. Disponível em:
<http://www.decom.ufop.br/romildo/cea030.2011-1/slides/
02-algoritmos>. Acesso em: 22 jul. 2020.
MCGOVERN, James; AMBLER, Scott W.; STEVENS,
Michael E.; LINN, James; SHARAN, Vikas; JO, Elias K. A
Practical Guide to Enterprise Architecture. Upper Saddle
River: Prentice Hall, 2004.
63 / 67
http://www.decom.ufop.br/romildo/cea030.2011-1/slides/02-algoritmos
http://www.decom.ufop.br/romildo/cea030.2011-1/slides/02-algoritmos
REFERÊNCIAS (cont.)
MEHTA, Nikunj R.; MEDVIDOVIC, Nenad. Composing
Architectural Styles from Architectural Primitives. In:
Proceedings of the 9th European Software Engineering
Conference and the 11th ACM SIGSOFT International
Symposium on Foundations of Software Engineering
(ESEC/FSE’03). Helsinki: ACM, 2003. p. 347–350.
MERSON, Paulo; SAINI, Darpan. OPC Module Uses
View. In: . Adventure Builder Software Architecture
Document (SAD). [s.n.], 2019. Disponível em: <https://wiki.sei.
cmu.edu/confluence/display/SAD/OPC+Module+Uses+View>.
Acesso em: 28 jul. 2020.
MONROE, Robert T.; KOMPANEK, Drew; MELTON, Ralph;
GARLAN, David. Architectural Styles, Design Patterns, and
Objects. IEEE Software, v. 14, n. 1, p. 43–52, 1997.
64 / 67
https://wiki.sei.cmu.edu/confluence/display/SAD/OPC+Module+Uses+View
https://wiki.sei.cmu.edu/confluence/display/SAD/OPC+Module+Uses+View
REFERÊNCIAS (cont.)
OBJECT MANAGEMENT GROUP. Unified Modeling
Language: Superstructure. v. 2.4.1. [S.l.], 2011. p. 1-732.
Disponível em: <http://www.omg.org/spec/UML/2.4.1/
Superstructure/PDF>. Acesso em: 04 dez. 2014.
PERRY, Dewayne E.; WOLF, Alexander L. Foundations for
the study of software architecture. ACM SIGSOFT Software
Engineering Notes, New York, v. 17, n. 4, p. 40–52, 1992.
PRIETO-DÍAZ, Rubén. Status Report: Software Reusability.
IEEE Software, v. 10, n. 3, p. 61–66, 1993.
QIAN, Kai; FU, Xiang; TAO, Lixin; XU, Chong-Wei;
DÍAZ-HERRERA, Jorge L. Software Architecture and Design
Illuminated. Sudbury: Jones and Bartlett Publishers, 2010.
65 / 67
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF
http://www.omg.org/spec/UML/2.4.1/Superstructure/PDF
REFERÊNCIAS (cont.)
QIAN, Lena; GERO, John S. Function-Behavior-Structure
Paths and Their Role in Analogy-Based Design. Artificial
Intelligence for Engineering Design, Analysis and
Manufacturing, Cambridge, v. 10, n. 4, p. 289–312, Sept.
1996. Disponível em: <http://journals.cambridge.org/action/
displayAbstract?fromPage=online&aid=4197416&fileId=
S0890060400001633>. Acesso em: 02 maio 2016.
ROZANSKI, Nick; WOODS, Eoin. Software Systems
Architecture: Working with Stakeholders Using Viewpoints and
Perspectives. 2nd. ed. Westford: Addison-Wesley, 2012.
SALEH, Kassem A. Software Engineering. [S.l.]: J. Ross
Publishing, 2009.
SHAN, Tony C.; HUA, Winnie W. Towards a Systematic
Method for Solutions Architecting. In: . Handbook
of Research on Modern Systems Analysis and Design
Technologies and Applications. Hershey: Information
Science Reference, 2009. cap. 1, p. 1–22.
66 / 67
http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=4197416&fileId=S0890060400001633
http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=4197416&fileId=S0890060400001633
http://journals.cambridge.org/action/displayAbstract?fromPage=online&aid=4197416&fileId=S0890060400001633
REFERÊNCIAS (cont.)
SOFTWARE. In: DICIONÁRIO Priberam da Língua
Portuguesa online. S.l.: s.n., 2020. Disponível em:
<https://dicionario.priberam.org/software>. Acesso em: 24 jul.
2020.
SOMMERVILLE, Ian. Software Engineering. 8th. ed.
Harlow: Addison-Wesley, 2007.
WIRSING, Martin; HOLZL, Matthias. Software Intensive
Systems. Final Report. Beyond the Horizon, Thematic Group
n. 6, p. 1-42, 2006. Disponível em: <http://www.pst.ifi.lmu.de/
~rauschma/interlink/cannes/groups/TG6.pdf>. Acesso em: 15
jan. 2015.
67 / 67
https://dicionario.priberam.org/software
http://www.pst.ifi.lmu.de/~rauschma/interlink/cannes/groups/TG6.pdf
http://www.pst.ifi.lmu.de/~rauschma/interlink/cannes/groups/TG6.pdf
	ARQUITETURA DE SISTEMAS
	Componentes de sistemas
	Definição da arquitetura de sistemas e componentes
	Camadas da arquitetura de sistemas
	Arquitetura de componentes
	Modelagem
	PROCESSO DE DESENVOLVIMENTO
	Gerenciamento de processos
	Objetivos das metodologias de desenvolvimento e gestão
	Especificação de componentes
	Interação entre componentes
	Aplicação da UML
	REQUISITOS
	Definição de requisitos
	Tipos de requisitos
	Técnicas de levantamento de requisitos
	Validação de requisitos
	Prototipação
	Modelagem conceitual de negócios e de sistemas
	COMPONENTIZAÇÃO
	Identificação dos componentes
	Modelagem dos artefatos do sistema
	Interação de componentes
	Especificação de componentes
	PROVISIONAMENTO E CONSTRUÇÃO
	Framework CCM (Corba Component Model)
	Especificação vs. construção
	Interfaces
	Interação com sistemas existentes e legados
	Construção
	TÓPICOS EM ARQUITETURA DE SISTEMASArquitetura Monolítica
	Arquitetura de Microsserviços
	Virtualização
	Containers