Arquitetura de Software

Prévia do material em texto

Centro de Computação e Tecnologia da 
Informação
Arquitetura de Software
Projeto de Software
Prof. Daniel Luis Notari
Agosto - 2012
Sumário
• Arquitetura lógica
• Arquitetura física
• Artefatos de diagramação
3
Introdução
• Questões relacionadas à arquitetura de um 
sistema:
– Como um sistema é decomposto em subsistemas,
e como as suas classes são dispostas pelos
diversos subsistemas?
– Como subsistemas devem ser dispostos
fisicamente quando o sistema tiver de ser
implantado?
4
Introdução
• Arquitetura de software é a estrutura 
organizacional do software.
• Uma arquitetura pode ser recursivamente 
decomposta em partes que interagem através 
de interfaces.
• As decisões tomadas para a definição da 
arquitetura de software influenciam 
diretamente PARA atender a seus requisitos 
não-funcionais.
5
Arquitetura lógica
• Chamamos de arquitetura lógica à organização 
das classes em subsistemas, que 
correspondem a aglomerados de classes. 
• Um subsistema provê serviços para outros 
através de sua interface.
• A interface de um subsistema corresponde ao
conjunto de serviços que ele provê.
– Cada subsistema provê ou utiliza serviços de 
outros subsistemas. 
Princípios de Análise e Projeto 
de Sistemas com UML - 2ª 
edição
6
Diagrama de subsistemas
– Um diagrama de susbistemas é um diagrama
de pacotes, onde cada pacote representa um 
subsistema
– Cada subsistema é rotulado com o estereótipo 
<<subsystem>>.
• Exemplo de susbsistema:
7
Alocação de classes a subsistemas
• Cada classe do sistema é, então, alocada 
aos subsistemas. 
• Uma vez feito isso, esses subsistemas 
podem ser desenvolvidos quase que de 
forma independente uns dos outros.
8
Alocação classes a subsistemas
• Modelo de classes de domínio: 
– Classes devem ser agrupadas segundo algum critério para formar 
subsistemas.
• Um critério de agrupamento possível: 
• considerar as classes mais importantes do modelo de classes de 
domínio.
– Para cada uma dessas classes, um subsistema é criado.
– Outras classes menos importantes e relacionadas a uma classe 
considerada importante são posicionadas no subsistema desta última.
9
Alocação classes a subsistemas
• Por outro lado, na fase de projeto:
– Algumas das classes do modelo de domínio podem sofrer 
decomposições adicionais, o que resulta em novas classes.
– Pode ser que uma classe de domínio seja ela própria um 
subsistema.
• Quando essas classes forem criadas, elas são adicionadas aos 
subsistemas pré-definidos.
10
Alocação classes a subsistemas
• Subsistemas devem ser
• minimamente acoplados.
• maximamente coesivos.
• Dependências cíclicas entre subsistemas devem ser evitadas.
• Uma classe deve ser definida em um único subsistema:
– O subsistema que define a classe deve mostrar todas as 
propriedades da mesma.
– Outros subsistemas que fazem referência a essa classe podem 
utilizar a notação simplificada da mesma.
Exercício
• De acordo com o modelo de classes do 
próximo slide, defina:
– Possíveis subsistemas
– Faça um diagrama dos subsistemas
– Aloque as classes a cada subsistema
13
Camadas de software
• Diz-se que dois subsistemas interagem quando um 
precisa dos serviços do outro.
• Há basicamente duas formas de interação entre 
subsistemas: 
– ponto a ponto: na arquitetura ponto a ponto, a 
comunicação pode acontecer em duas vias. 
– cliente-servidor: há a comunicação somente em uma via 
entre dois subsistemas, do cliente para o servidor. Nessa
arquitetura, chamamos de camadas os subsistemas
envolvidos. 
• Essas formas de interação entre subsistemas 
influenciam a o modo pelo qual os subsistemas são 
distribuídos fisicamente pelos nós de processamento. 
14
Camadas de software
• Arquiteturas cliente-servidor e ponto a ponto
15
Camadas de software
• As camadas podem ter uma arquitetura aberta
ou uma arquitetura fechada. 
– Em uma arquitetura fechada, um componente de uma 
camada de certo nível somente pode utilizar os 
serviços de componentes da sua própria camada ou 
da imediatamente inferior. 
– Em uma arquitetura aberta, uma camada em certo 
nível pode utilizar os serviços de qualquer camada 
inferior.
• Na maioria dos casos práticos, encontramos 
sistemas construídos através do uso de uma 
arquitetura aberta.
16
Camadas de software
• Arquiteturas abertas e fechadas
17
Camadas de software
• Uma divisão tipicamente encontrada para 
as camadas lógicas é a que separa o sistema 
nas seguintes camadas: 
– apresentação, aplicação, domínio e serviços 
técnicos. 
• Da esquerda para a direita, temos camadas 
cada vez mais genéricas. 
• Também da esquerda para a direita, temos a 
ordem de dependência entre as camadas; 
– por exemplo a camada da apresentação 
depende (requisita serviços) da camada de 
aplicação, mas não o contrário. 
18
Camadas de software
• Princípio básico: camadas mais altas devem depender das 
camadas mais baixas, e não o contrário. 
– Essa disposição ajuda a gerenciar a complexidade através 
da divisão do sistema em partes menos complexas que o 
todo.
– Também incentiva o reuso, porque as camadas inferiores 
são projetadas para serem independentes das camadas 
superiores. 
– O acoplamento entre camadas é mantido no nível mínimo 
possível. 
– Uma mudança em uma camada mais baixa que não afete a 
sua interface não implicará em mudanças nas camadas 
mais altas.
– E vice-versa, uma mudança em uma camada mais alta que 
não implica na criação de um novo serviço em uma 
camada mais baixa não irá afetar estas últimas.
19
Camadas de software
• É importante notar que uma aplicação típica
normalmente possui diversos subsistemas
(ou pacotes) internamente a cada uma das
camadas.
– Por exemplo, em uma aplicação que forneça
certo serviço que é acessível tanto por um
usuário final, quando por outra aplicação (através
de um serviço WEB), há duas camadas de
aplicação, possivelmente fazendo acesso a
mesma camada da aplicação.
20
Camadas de software
• Uma certa camada pode ser dividida
verticalmente no que costumamos chamar
de partições.
– Por exemplo, em um sistema de vendas pela 
WEB, a camada de domínio pode ser 
decomposta nos seguintes subsistemas 
(partições): Clientes, Pedidos e Entregas.
Implantação física
22
Arquitetura de implantação
• Representa a disposição física do sistema de software pelo 
hardware disponível. 
• A divisão de um sistema em camadas é independente da 
sua disposição física.
– As camadas de software podem estar fisicamente localizadas 
em uma única máquina, ou podem estar distribuídas por 
diversos processadores.
– Alternativamente, essas camadas podem estar distribuídas 
fisicamente em vários processadores.
23
Arquitetura de implantação
• O modelo que representa a arquitetura física é 
denominado modelo de implementação ou modelo da 
arquitetura física.
• A arquitetura de implantação diz respeito à disposição dos 
subsistemas pelos nós de processamento disponíveis. 
• Para sistemas simples, a arquitetura de implantação não 
tem tanta importância.
24
Arquitetura de implantação
• No entanto, na modelagem de sistemas 
complexos, é fundamental conhecer quais são 
os componentes físicos do sistema, quais são 
as interdependências entre eles e de que 
forma as camadas lógicas do sistema são 
dispostas por esses componentes.
25
Alocação de camadas
• Em um sistema construído segundo a 
arquitetura a cliente-servidor, é comum 
utilizar as definições das camadas lógicas 
como um guia para a alocação física dos 
subsistemas.
• Sendo assim, a cada nó de 
processamentosão alocadas uma ou 
mais camadas lógicas.
26
Alocação de camadas
• Note que o termo camada é normalmente
utilizado com dois sentidos diferentes: 
– para significar uma camada lógica (layer)
– e para significar uma camada física, esta 
última normalmente associada a um nó de 
processamento (tier). 
27
Alocação de camadas
• Vantagens da alocação das camadas lógicas 
a diferentes nós de processamento:
– A divisão dos objetos permite um maior grau de 
manutenção e reutilização, porque sistemas de 
software construídos em camadas podem ser 
mais facilmente estendidos. 
– Sistemas em camadas também são mais 
adaptáveis a uma quantidade maior de usuários. 
• Servidores mais potentes podem ser acrescentados 
para compensar um eventual crescimento no número 
de usuários do sistema. 
28
Alocação de camadas
• No entanto, a divisão do sistema em 
camadas apresenta a desvantagem de 
potencialmente diminuir o desempenho do 
mesmo.
– a cada camada, as representações dos 
objetos sofrem modificações, e essas 
modificações levam tempo para serem 
realizadas.
29
Duas Camadas
• Um sistema que divide a interação com o 
usuário e o acesso aos dados em dois 
subsistemas é denominado sistema cliente-
servidor em duas camadas.
• A construção de sistemas em duas camadas é 
vantajosa quando o número de clientes não é 
tão grande (por exemplo, uma centena de 
clientes interagindo com o servidor através de 
uma rede local). 
30
Duas Camadas
• No entanto, com o surgimento da Internet
causou problemas em relação à estratégia 
cliente-servidor em duas camadas.
– Isso porque a ideia básica da Internet é permitir o 
acesso a variados recursos através de um 
programa navegador (browser).
31
Três Camadas
• A solução encontrada para o 
problema da arquitetura em duas 
camadas foi simplesmente dividir o 
sistemas em mais camadas de 
software.
– Sistemas construídos segundo essa 
estratégia são denominados sistemas 
cliente-servidor em três camadas ou 
sistemas cliente-servidor em quatro 
camadas.
32
Três Camadas
• Entretanto, a ideia básica original 
permanece: dividir o processamento 
do sistema em diversos nós. 
– Em particular, uma disposição bastante 
popular, principalmente em aplicações 
para a WEB, é a arquitetura cliente-
servidor em três camadas.
33
Três Camadas
– A camada lógica de apresentação fica em um 
nó de processamento.
– As camadas lógicas da aplicação e do 
domínio ficam juntas em outro nó :
• A camada física do meio corresponde ao 
servidor da aplicação.
• A camada de apresentação requisita serviços ao 
servidor da aplicação.
• É também possível haver mais de um servidor de 
aplicação, com o objetivo de aumentar a 
disponibilidade e o desempenho da aplicação. 
34
Três Camadas
– A camada física do meio faz acesso a 
outra camada física, onde normalmente se 
encontra um SGBD.
• Esta última camada física é chamada de 
camada de dados.
35
Diagrama de implantação
• Uma vez definidas as alocações das 
camadas lógicas aos nós de 
processamento, pode-se fazer a 
representação gráfica com suporte da
UML, através do diagrama de 
implantação.
• Os elementos desse diagrama são os nós
e as conexões.
36
Diagrama de implantação
• Um nó representa um recurso computacional e
normalmente possui uma memória e alguma
capacidade de processamento.
– Exemplos: processadores, dispositivos, sensores,
roteadores ou qualquer objeto físico de importância
para o sistema de software.
• Os nós são ligados uns aos outros através de
conexões.
– As conexões representam mecanismos de
comunicação: meios físicos (cabo coaxial, fibra ótica
etc.) ou protocolos de comunicação (TCP/IP, HTTP
etc.).
Princípios de Análise e Projeto 
de Sistemas com UML - 2ª 
edição
37
Exemplo de diagrama de implantação
Exercício
• Desenhe o diagrama de implantação para o 
exercício anterior.
39
Alocação de Componentes
• Na arquitetura (alocação) física, devemos
também definir quais os componentes de 
software de cada camada.
• Um componente de software é uma unidade 
que existe a tempo de execução, que pode ser 
utilizada na construção de vários sistemas e 
que pode ser substituída por outra unidade 
que tenha a mesma funcionalidade.
40
Alocação de Componentes
• As tecnologias COM (Microsoft), CORBA 
(OMG) e EJB (Sun) são exemplos de 
tecnologias baseadas em componentes.
• Um componente provê acesso aos seus 
serviços através de uma interface.
– Quando construído segundo o paradigma OO, um 
componente é composto de diversos objetos.
– Nesse caso, a interface do componente é 
constituída de um ou mais serviços que as classes 
dos referidos objetos implementam.
41
Alocação de Componentes
• A UML define uma forma gráfica para 
representar componentes visualmente, o 
diagrama de componentes. 
• Esse diagrama mostra os vários componentes 
de software e suas dependências.
• Os elementos gráficos desse diagrama são 
ilustrados na figura abaixo.
42
Alocação de Componentes
• Exemplo de diagrama de componentes.
43
Alocação de Componentes
• Alternativas para representar interfaces de
componentes.
44
Alocação de Componentes
• Exemplo de diagrama de componentes 
embutido em um diagrama de implantação.
45
Alocação de Componentes
• A atividade de alocação de componentes aos nós 
físicos só tem sentido para sistemas distribuídos.
– Para sistemas que utilizam um único processador, não 
há necessidade desta atividade.
• Um dos principais objetivos: distribuir a carga de 
processamento do sistema para aumentar o 
desempenho.
– No entanto, nem sempre isso aumenta o 
desempenho.
– Isso porque a sobrecarga de comunicação entre os nós 
pode anular os ganhos obtidos com a distribuição do 
processamento.
46
Alocação de Componentes
• Envio de mensagem versus “distância”
– dentro de um processo executando em um nó.
– entre processos no mesmo nó.
– ultrapassa as fronteiras de um nó para ser executada 
em outra máquina.
• Portanto, durante a alocação de componentes, o 
arquiteto de software deve considerar diversos 
fatores.
– muitos desses fatores se sobrepõem ou são 
incompatíveis.
47
Alocação de Componentes
• Fatores relacionados ao desempenho:
– Utilização de dispositivos
– Carga computacional
– Capacidade de processamento dos nós
– Realização de tarefas
– Tempo de resposta
48
Alocação de Componentes
• Outros fatores:
– Outros requisitos não funcionais do sistema
– Segurança
– Diferenças de plataformas
– Características dos usuários do sistema
– Necessidade ou benefícios da distribuição das 
camadas lógicas do sistema
– Redundância
Projeto da arquitetura no 
processo de desenvolvimento 
de software 
50
Projeto de Arquitetura
• A construção dos diagramas de componentes é 
iniciada na fase de elaboração (projeto da 
arquitetura) e refinada na fase de construção 
(projeto detalhado).
• A construção de diagramas de componentes se 
justifica para componentes de execução.
– permite visualizar as dependências entre os 
componentes e a utilização de interfaces a tempo de 
execução do sistema.
– sistema distribuído: representar seus componentes 
utilizando diagramas de implantação.
51
Projeto de Arquitetura
• Não é recomendável usar diagramas de 
componentes para representar dependências de 
compilação entre os elementos do código fonte 
do sistema.
– A maioria dos ambientes de desenvolvimento tem 
capacidade de manter as dependências entre códigos 
fonte, códigos objeto, códigos executáveis e páginas 
de script.
– Só adiciona mais diagramas que terão que ser 
mantidos e que não terãouma real utilidade.
– Há também vários sistemas de gerenciamento de 
configurações e de versões de código (e.g, CVS). 
52
Projeto de Arquitetura
• Em relação ao diagrama de implantação, sua 
construção tem início na fase de elaboração. 
• Na fase de construção, os componentes são 
adicionados aos diversos nós.
• Nem todo sistema necessita de diagramas de 
componentes ou diagramas de implantação.
– Sistemas simples versus sistemas complexos.
Workflow Arquitetura
• Selecionar um tipo de arquitetura para o sistema
• Criar um diagrama de Implantação para casos de 
uso arquiteturalmente significantes
• Refinar o Modelo Arquitetura para satisfazer os 
RNFs (Requisitos Não-Funcionais).
• Criar e testar a linha de base da arquitetura
• Documentar as escolhas tecnológicas em 
camadas de um diagrama de Pacotes
• Criar um template da arquitetura, do diagrama de 
Implantação detalhado.
Visões Arquiteturais
• As visões do Modelo Arquitetura possuem 
muitas formas.
• Alguns elementos são documentados com 
texto. 
• Outros podem ser salvos usando diagramas 
UML:
– Diagramas de Pacotes
– Diagramas de Componentes
– Diagramas de Implantação
Características de um Componente
• Um componente representa qualquer unidade de 
software
• Um componente pode ser grande e abstrato
• Um componente pode ser pequeno
• Um componente pode ter uma interface que 
exporta como um serviço para outros 
componentes
• Um componente pode ser um arquivo, como um 
código fonte, um objeto, um executável 
completo, um arquivo de dados, arquivos HTML 
ou mídia, e assim por diante.
O Objetivo de um Diagrama de 
Implantação
• Um nó do Hardware pode representar 
qualquer tipo de Hardware físico
• Links entre nós do Hardware indicam 
conectividade e podem incluir os protocolos 
de comunicação usados entre os nós.
• Os componentes do Software são colocados 
dentro dos nós do Hardware para mostrar a 
distribuição do Software através da rede.
Selecionando o Tipo de Arquitetura
• A arquitetura que você usa depende de 
muitos fatores, incluindo:
– As restrições da plataforma nos requisitos do 
sistema
– A maneira da interação do usuário
– Mecanismo de persistência
– Dados e integridade transacional
Selecionando o Tipo de Arquitetura
• Há centenas de arquiteturas de Software bem 
sucedidas. Aqui estão alguns tipos mais 
comuns:
– Aplicações StandAlone (Desktop)
– Aplicações Cliente/Servidor (2-camadas)
– Aplicações N-camadas
– Aplicações N- camadas centradas na Web
– Aplicações Corporativas N-camadas
Exercício
• Para o diagrama de classes apresentado no 
primeiro exercício:
1. Elabore um projeto de arquitetura lógica e física para 
que este software seja desenvolvido para a Web.
2. Defina também todos os programas a serem 
desenvolvidos (usando Java ou C#) para a camada de 
negócio.
3. Defina a linguagem da camada de apresentação.
4. Defina o SGBD a ser utilizado.
5. Defina o mecanismo de comunicação entre as 
camadas.
Centro de Computação e Tecnologia da 
Informação
Arquitetura de Software 
Segunda parte
Projeto de Software
Prof. Daniel Luis Notari
Agosto - 2012
Sumário
• Estilos Arquiteturais
• Frameworks
• Padrões de Projeto
• Projeto de classes reutilizáveis
Estilos Arquiteturais
Estilo Arquitetural
• Um estilo (padrão) arquitetural expressa um 
esquema de estrutura organizado para os 
sistemas de software. 
• Um padrão fornece um conjunto de 
subsistemas pré-definidos, específica as suas 
responsabilidades, e inclui regras e normas 
para organizar as relações entre eles.
Estilo Arquitetural
• Um critério importante para o sucesso dos 
padrões é que ele atenda, de maneira 
satisfatória, os objetivos da engenharia de 
software. 
• Os padrões devem suportar o 
desenvolvimento, manutenção e evolução de 
sistemas complexos e em grande escala.
• Eles também devem suportar efetivamente a 
produção industrial de software.
Estilo Arquitetural
• Os padrões tratam de um importante objetivo 
da engenharia de software: 
– a construção de arquiteturas de software 
específicas com propriedades definidas. 
– Usam características de orientação a objetos
• A criação de arquiteturas específicas é ainda 
baseada na intuição e na experiência.
Estilo Arquitetural
• Os níveis de arquiteturas de software de projeto 
são 
– tópicos estruturais que incluem a organização de um 
sistema como uma composição de componentes; 
– o controle global de estruturas;
– os protocolos para comunicação, sincronização e 
acesso aos dados; 
– a distribuição física; 
– o escalonamento e o desempenho; 
– a dimensão da evolução; 
– e a seleção entre projetos alternativos.
Estilo Arquitetural: categorias
• Estrutural :
– Os padrões desta categoria suportam uma
decomposição controlada de uma tarefa de um
sistema inteiro em subtarefas cooperativas.
– Esta categoria inclui os padrões em camadas, pipes e
filtros, e o padrão blackboard.
• Sistemas Distribuídos : 
– Esta categoria inclui somente o padrão broker.
– O padrão broker fornece uma completa infra-
estrutura para aplicações distribuídas.
Estilo Arquitetural: categorias
• Sistemas Interativos : 
– Esta categoria inclui dois padrões: Model-View-
Controller, mais conhecido como MVC, e o padrão 
Controle de apresentação e abstração. 
– Ambos os padrões suportam a estrutura de sistemas 
de software que caracteriza a interação ser humano e 
computador.
• Sistemas Adaptáveis : 
– O padrão reflexão e o padrão micro-kernel suportam 
extensões de aplicações e sua adaptação envolve 
requisitos de tecnologia e mudanças funcionais.
Pipes e Filtros
• Fornece uma estrutura para sistemas que 
processam um fluxo de dados. 
• Cada etapa de processamento é encapsulada 
em um componente do tipo filtro. 
• O dado é passado através dos pipes entre 
filtros adjacentes.
Sistemas em camadas
• Um sistema em camadas é organizado 
hierarquicamente, aonde cada camada 
fornece serviços para a camada superior e 
serve como um cliente para a camada inferior. 
• Passos para a criação de um sistema em 
camadas:
1. Definir os critérios de abstração: 
– Isto deve ser feito para agrupar as tarefas nas 
camadas.
Sistema em camadas
2. Determinar o número de níveis de abstração: 
– Este número é determinado de acordo com o critério de 
abstração.
3. Nomear as camadas e determinar as tarefas de cada 
camada.
4. Especificar os serviços:
– O mais importante princípio de implementação é que as 
camadas sejam cuidadosamente separadas uma da outra.
5. Refinar as camadas:
– Geralmente não é possível definir um critério de abstração 
preciso antes de pensar sobre as camadas envolvidas e seus 
serviços.
Sistema em camadas
6. Especificar a interface de cada camada:
– Definir a assinatura dos métodos a serem 
chamados pelas outras camadas
– Definir o tipo de retorno de cada método
7. Estruturar as camadas individuais
8. Especificar a comunicação entre as camadas 
adjacentes
9. Projetar uma estratégia para manipulação de 
erros
Blackboard
• É útil para problemas, para os quais, 
estratégias de soluções não determinísticas 
são conhecidas. 
Blackboard
Broker
• Usado para estruturar sistemas de software 
distribuídos com componentes separados que 
interagem pela invocação de serviços 
remotos. 
• m componente broker é responsável por 
comunicação coordenada, também como, 
transmitir resultados e exceções.
• É um padrão de projeto.
Broker
MVC (Model View Controller)
 Divide uma aplicação interativa em três 
componentes:
 O modelo (model) contémo núcleo funcional e os 
dados. 
 A visão (view) mostra as informações para o usuário. 
 O controlador (controller) manipula as entradas do 
usuário. 
 As visões e os controladores juntos compreendem 
a interface do usuário. 
 Um mecanismo de propagação de mudanças 
assegura consistência entre a interface do usuário 
e o modelo.
MVC (Model View Controller)
 Fortemente relacionada com padrões de projeto.
 Aplicações web utilizam muito esse modelo.
 O mecanismo de persistência é normalmente encapsulado 
pela camada de modelo.
 A camada de apresentação é dividida entre o Controller e o 
View.
 Exemplos:
 Java Swing
 QT tookit (GIU Linux)
 Microsoft Foundation Classes
 Java server Faces
 Apache Struts
 MVVM (Microsoft)
MVC (Model View Controller)
Frameworks
Frameworks
 Características:
 Projeto em larga escala que descreve como 
um sistema é decomposto em um conjunto de 
objetos que interagem.
 Representado como um conjunto de classes 
abstratas e a maneira como elas interagem
 Utilizam inversão de controle
 Utilizam padrões de projeto e componentes
Framework: Reuso de software
Rotinas Classes Componentes Padrões Frameworks
 Componentes: Primeira visão de reuso
 Padrões de Projeto: Reuso de Projeto
 Frameworks: Reuso de Projeto e Reuso de Código
Framework: Reuso de software
 O uso de componentes visa aumentar o 
grau de reuso no desenvolvimento de 
software 
 Isto é feito através de dois processos:
– Engenharia de domínio
– Desenvolvimento baseado em componentes
Exemplo de framework - FraG
Frameworks
 Estrutura de Classes
 Orientação a Objetos
 Implementação Inacabada
Aplicação OO completamente 
Desenvolvida
Reutilização de Classes
Aplicação baseada em framework
Frameworks
 Frameworks são uma técnica de reuso de 
software OO
 Definição:
 Projeto reutilizável de parte de um sistema, 
representado por um conjunto de classes 
abstratas e seu inter-relacionamento 
(estrutura)
 Esqueleto de uma aplicação que pode ser 
customizado pelo desenvolvedor (propósito)
Componentes
 As tecnologias de reuso ideais provêm 
componentes que podem ser conectados para 
produzir um novo sistema
 O desenvolvedor não precisa saber como o 
componente é implementado. O componente 
provê uma interface para comunicação.
 A especificação do componente é de fácil 
entendimento
 Sistema resultante será eficiente, fácil de manter 
e recuperar
Componentes
Simples,
Inflexíveis,
Pouco Usados
Complexos,
Flexíveis,
Muito Utilizados
Motivações para o uso de 
frameworks e reuso
 Principal: Economizar tempo e dinheiro no 
desenvolvimento de software
 Uniformidade
 Construção de Sistemas Abertos
 Combinação de Softwares Diferentes
 Linguagens OO: Frameworks para 
interfaces gráficas
O que é um Framework?
 Classes Abstratas
 Classes sem instâncias, são usadas como 
superclasses
 Classes abstratas protelam a implementação 
de alguns de seus métodos para suas 
subclasses
 São utilizadas como modelos para a criação de 
classes
 Frameworks utilizam classes abstratas 
como projeto para seus componentes
Classes abstratas
 Classes abstratas definem uma interface 
para suas subclasses
 Clientes das subclasses da classe abstrata 
precisam de uma classe que implemente a 
interface da classes abstrata
 Classes abstratas podem prover parte da 
implementação dos métodos:
 Métodos Template
Métodos Template
 Definem o esqueleto de um algoritmo de 
um método em uma classe abstrata, 
prorrogando passos da implementação, 
delegando-os para as subclasses
 Métodos Hook
 Subclasses concretas devem implementar 
os métodos abstratos providos pela classe 
abstrata
Frameworks
 Projeto em larga escala que descreve como 
um sistema é decomposto em um conjunto 
de objetos que interagem entre si
 Normalmente representado como um 
conjunto de classes abstratas e a maneira 
como elas interagem
 Reuso de interface é mais importante que 
reuso de implementação
Frameworks
 Tiram proveito das seguintes 
características das linguagens OO:
 Abstrações
 Polimorfismo
 Herança
Inversão de controle
 Normalmente usuários de componentes 
chamam os componentes sempre que 
necessário
 sendo responsável pela estrutura e pelo fluxo 
de controle do programa 
 Ao utilizar frameworks o código do usuário 
é chamado pelo framework
 O framework é responsável pela estrutura e 
pelo fluxo de controle do programa 
Frameworks
 Frameworks para vários domínios:
 Interfaces gráficas
 Sistemas Hipermídia
 Editores Gráficos
 Sistemas Operacionais
 Protocolos de Rede
 ...
Frameworks
 Frameworks reutilizam código pq tornam mais 
fácil o desenvolvimento de uma aplicação através 
de uma biblioteca de componentes existentes
 Provêm uma interface padrão para o inter-
relacionamento entre objetos
 Frameworks reutilizam análise
 Modelam um domínio de aplicação
 Generalizam um domínio de aplicações
Alguns problemas com frameworks
 Como são complexos e flexíveis, 
normalmente são difíceis de utilizar
 Requerem melhor documentação
 Requerem melhor treinamento
 São mais difíceis de desenvolver
 Dependentes de linguagem
Padrões de Projeto
Padrões de Projeto
 Difícil construir software reutilizável
 Reutilização de soluções que funcionaram 
no passado
 Resolve problemas específicos
 Tornam o software mais flexível
 Registram experiências no projeto de 
software
 Nomeiam, explicam e avaliam soluções
Padrões de projeto
 Nome do padrão
 Problema
 Solução
 Conseqüências
Definição
 “Descrições de objetos e classes 
comunicantes que são customizados para 
resolver um problema geral de projeto em 
um contexto particular”
Padrões de projeto
 Identificam as classes e instâncias, seus 
papéis, responsabilidades e colaborações
Exemplo de um padrão (Observer)
 Intenção
 Define uma dependência um para muitos 
entre objetos, de modo que quando o objeto 
muda de estado, todos seus dependentes são 
notificados e atualizados
Observer
Observer
 Desafios: 
 Manter a consistência entre visões de forma a 
manter baixo o acoplamento
 Ao modificar uma das visões, as outras tomam 
conhecimento
Observer
 Aplicabilidade:
 Quando a aplicação tem duas preocupações 
dependentes entre si
 Quando uma mudança em um componente 
exige mudança em outros, mesmo que vc não 
saiba quantos objetos necessitam ser 
mudados
Observer (Estrutura)
Participantes
 Subject
 Conhece seus observadores
 Fornece uma interface para acrescentar e 
remover objetos, associando e desassociando 
objetos observers
 Observer
 Define uma interface de atualização para 
objetos que deveriam ser notificados sobre 
mudanças em um subject
Participantes
 ConcreteSubject
 Armazena estados de interesse para objetos 
ConcreteObserver
 Envia uma notificação para seus observadores quando 
seu estado muda
 ConcreteObserver
 Mantém uma referência para o ConcreteSubject
 Armazena estados que devem ser consistentes com o 
subject
 Implementa a interface de atualização de Observer
aConcreteSubject : 
ConcreteSubject
aConcreteObserver 
: ConcreteObserver
anotherConcreteObserver : 
ConcreteObserver
1: SetState( )
2: Notify( )
3: Update( )
4: GetState( )
5: Update( )
6: GetState( )
Benefícios e deficiências do uso do 
padrão Observer
 Acoplamento abstrato entre Subject e 
Observer
 Suporte para comunicações BroadCast
 Atualizações inesperadasProjetando classes reutilizáveis
Introdução
 OO é normalmente lembrada como uma 
técnica que facilita o reuso
 Facilita o desenvolvimento, manutenção ...
 Para isso componentes devem ser 
projetados para serem reutilizáveis
 Existem várias técnicas que tornam isso 
possível
OO
 Provê modularidade e ocultamento de 
informações como tipos de dados 
abstratos
 Duas características que facilitam reuso:
 Herança
 Classes abstratas
 Polimorfismo
 Conjunto de mensagens com mesma assinatura e 
comportamentos diferentes
Polimorfismo
 Operações são realizadas ao enviarmos 
uma mensagem a um objeto
 A mensagem é avaliada de acordo com a 
classe do objeto que a chama
Interfaces
 A especificação da interface de utilização de um 
objeto é dado pelas operações que podem ser 
realizadas por ele
 Conjunto de mensagens que podem ser enviadas
 Objetos com interfaces iguais são intercambiáveis
 Formam vocabulário comum entre 
desenvolvedores
Herança
 Cada classe de um sistema possui uma 
superclasse que define suas operações e 
estruturas de dados
 Uma classe pode adicionar operações ou 
modificar operações definidas nas 
superclasses
Herança
 A herança promove reuso pq o código 
utilizado por um conjunto de classes pode 
ser encapsulado em uma superclasse 
comum
 Subclasses já iniciam com as 
funcionalidades da superclasse
 Programação por diferença
 Mudanças aditivas
Herança
 Possibilita uma maneira de organizar e 
classificar classes
 Encoraja o desenvolvimento de protocolos 
padrões, facilitando o polimorfismo
 Mudanças não invasivas
Classes abstratas
 Interfaces normalmente são expressas através de 
classes abstratas
 Servem como um esqueleto que é reusado pelas 
subclasses
 Muitas vezes é mais vantajoso herdar de uma 
classe abstrata do que de uma classe concreta
 Classes concretas dependem da estrutura de dados 
utilizada
Classes abstratas
 Benefícios da manipulação de objetos somente 
através de interfaces definidas por classes 
abstratas:
 Clientes permanecem sem conhecimento dos tipos 
específicos dos objetos manipulados
 Clientes conhecem apenas as classes abstratas que 
definem a interface
 Programa para uma interface e não para uma 
implementação
 Declare variáveis como instâncias de classes 
abstratas
Regras para projeto OO
 #1 - Eliminar checagem de tipos de classe 
em tempo de execução
 Ex.: 
anObject class == ThisClass 
ifTrue: [anObject foo]
ifFalse: [anObject fee]
Regras para projeto OO
 #2 – Reduzir o número de argumentos de 
métodos
 Quebrar o método em diversos menores
 Criar uma nova classe para representar os 
argumentos
Regras para projeto OO
 #3 – Reduzir o corpo dos métodos
 Manter métodos pequenos permite 
sobrescrever pouco código ao utilizarmos 
subclasses
Regras para projeto OO
• #4 – Hierarquias de classes devem possuir 
vários níveis de profundidade e possuir 
pouca largura
• #5 – O topo de hierarquias de classes deve 
ser abstrato
• #6 – Minimize acesso as variáveis
– Acesso a variáveis somente através de 
mensagens
Regras para projeto OO
 #7 - Quebrar classes grandes
 Uma classe supostamente representa uma 
abstração
 Classes com uma quantidade muito grande de 
métodos (+50) normalmente representam 
várias abstrações
Regras para projeto OO
 #8 – Separar métodos que não se 
comunicam
 Muitas vezes metade dos métodos de uma 
classe acessam metade das variáveis e a outra 
metade o resto das variáveis
 É mais interessante quebrar a classe em duas 
classes independentes
Regras para projeto OO
 #9- Enviar mensagens para componentes e 
não para si próprio
 Delegar responsabilidades entre componentes 
diferentes flexibiliza a estrutura da aplicação
Herança versus composição
 Vantagens da Herança
 Simples de usar
 Definida estaticamente
 Fácil de modificar a implementação q está 
sendo reutilizada
Herança versus composição
 Desvantagens da herança
 Implementações não podem ser mudadas em 
tempo de execução
 Herança pode violar encapsulamento 
amarrando subclasses a uma estrutura 
específica
Herança versus composição
 Vantagens da composição
 Programação para uma interface bem definida
 Comportamento modificado durante execução
 Menos dependências entre classes
 Melhor distribuição de responsabilidades
 Favoreça a composição de objetos em 
relação a herança
Diferenças entre frameworks e 
padrões de projeto
 Padrões de projeto são mais abstratos que 
frameworks
 Padrões de projeto são elementos 
menores na arquitetura de um sistema. 
 Um framework pode conter vários padrões de 
projeto implementados
 Padrões são menos especializados que 
frameworks
Exercícios
1. Defina o que é um estilo arquitetural.
2. Defina o que é um framework.
3. Pesquise na Internet frameworks para as 
situações abaixo e explique o seu uso:
– Modelagem Objeto-Relacional
– Criação de interfaces gráficas
– Geração de código baseado na definição de 
regras de negócio.
Exercícios
4. Pesquise quais são as categorias de padrões de 
projeto existentes. Cite pelo menos seis 
diferentes. Cite os padrões de projeto de cada 
categoria.
5. Explique o que uma empresa deve levar em 
consideração para escolher um framework para 
o desenvolvimento de qualquer parte de um 
software.
6. Explique como os programadores devem usar 
padrões de projeto para solucionar problemas 
específicos.
Exercícios
7. Você acredita em reuso de software. Justifique 
a sua resposta.
8. Você acredita em programação orientada a 
objeto para desenvolver softwares complexos 
para a Web? Justifique a sua resposta.
9. Você acredita no uso de frameworks ou 
geradores de código para desenvolver um 
sistema complexo? Que tipo de controle 
temos sobre estas ferramentas? Justifique a 
sua resposta.
Exercícios
10. Explique o estilo de arquitetura orientada a 
serviços.
11. Explique o estilo de arquitetura utilizado 
para a construção de um Data Warehouse 
componente de um sistema de BI (Business 
Inteligence).
12. Pesquise outros estilos arquiteturais 
utilizados por diferentes tipos de softwares.
Centro de Computação e Tecnologia da 
Informação
Arquitetura de Software 
Terceira parte
Projeto de Software
Prof. Daniel Luis Notari
Agosto - 2012
Sumário
• Framework JEE
• Framework .NET
Introdução
• Java Enterprise Edition
• Voltado ao desenvolvimento de aplicações 
empresariais 
• Foco em componentização para reduzir custos de 
desenvolvimento e manutenção
• Independentes de plataforma
• Provê um modelo de aplicações distribuídas em 
camadas
• Uma aplicação JEE é composta por componentes
Introdução
• A plataforma JEE oferece:
– Modelo de aplicações distribuídas em camadas,
– Componentes reusáveis,
– Modelo de segurança unificado,
– Controle de transações flexível, e
– Troca de dados integrada baseada em XML.
Introdução
• A arquitetura em camadas mais conhecida é a 
baseada em 3 camadas
– Uma camada para lidar com a interface, interface 
executa no computador cliente e no servidor JEE.
– Uma para lidar com a lógica da aplicação, executa 
no servidor JEE.
– Uma para gerenciar acesso a banco de dados, 
executa no EIS (Enterprise Information System).
Introdução
Introdução
• Um componente JEE é uma unidade funcional auto-
contida, 
– que pode ser montada em uma aplicação JEE com suas 
classes e arquivos relacionados, 
– e que se comunica com outros componentes.
• Interface
– Clientes de aplicação e Applets são componentes cliente
– Java Server Pages (JSP) são componentes web• Controle
– Java Servlets são componentes web
• Lógica
– Enterprise JavaBeans (EJB) são componentes lógicos
Introdução
• Applets
– São pequenas aplicações clientes escritas em Java e que 
executam na máquina virtual de um browser
– Applets são obtidos durante o download de uma página
• Java Bean
– Um JavaBean é uma classe em Java, escrita normalmente. 
– JSP fornece formas de utilização automática para um Java Bean.
• Servlets
– Classes que processam pedidos e geram respostas 
dinamicamente
• JSP
– Documentos baseados em texto que executam como servlets
– Fornecem uma maneira mais natural de gerar conteúdo estático
Comunicação com o J2EE Server
Thin Clients
• Interfaces bem simples
• Delegam todas as tarefas mais complexas para 
o servidor JEE
– Acesso a bancos de dados
– Conexão com sistemas legados
Arquitetura de Aplicações J2EE
Arquitetura de Aplicações J2EE
Contêineres e Serviços
• Componentes são instalados em seus contêineres 
durante a implantação
– Contêineres são a interface entre o componente e o 
serviço específico da plataforma que ele provê
• Antes de serem usados, componentes devem ser 
montados numa aplicação JEE e implantado 
(“deployed”) em seu contêiner
• A montagem envolve especificar a configuração:
– de contêiner para cada componente implantado para 
a própria aplicação JEE
Contêineres e Serviços
• As configurações de contêiner customizam o 
suporte fornecido pelo servidor JEE
– Segurança
– Transação
– Servidor de nomes
– Remote Conectivity
Configuração do JEE
• Cada componente dentro de uma mesma 
aplicação pode ter diferentes 
comportamentos
– Função do local de implantação
• Exemplo:
– Um EJB pode ter diferentes permissões de acesso 
em diferentes ambientes de produção
Tipos de Contêiner
• Tipos de contêiner:
– Contêiner Enterprise JavaBeans
– Contêiner Web 
• JSP e Java Servlets
– Contêiner de Clientes da Aplicação
• Executa na máquina cliente
– Contêiner de Applet
• Web browser
Tipos de Contêiner
Empacotamento
• Uma aplicação JEE é 
composta por
– Um ou mais EJB
– Um ou mais módulos 
de componentes web
– Um ou mais módulos 
de componentes 
clientes
Componentes Web
DTO = VO
Framework .NET
Objetivo
• Apresentar os principais componentes do 
framework, bem como as possibilidades de 
desenvolvimento de aplicações
Roteiro
• Introdução ao .NET
• Framework .NET
• Common language runtime
• Tipos de Aplicações
– Interface com o usuário
– Camada de Negócio 
– Acesso a bancos de dados
Serviços de
Infra
Tecnologias MS:
COM, IIS (ASP) e Internet Explorer
Introdução ao .NET
Cenário ~1996
Aplicações empregavam o 
modelo cliente/servidor, com 
páginas ASP acessando 
servidores de dados
Navegadores
Aplicações baseadas em HTML, 
sem interatividade
Servidores
de Dados
Lógica
do Cliente
Lógica 
de Negócio
Componentes sem estado e gerenciamento de 
IP favorecem a escalabilidade.
Com estado
Sem estado
Cliente rico
Introdução ao .NET 
Cenário ~2000 - Escalabilidade
SGBD
Serviços 
básicos
Lógica de 
negócio
Navegadores
Separação das camadas de 
dados e negócios 
aumentam a escalabilidade 
e a performance de acesso a 
dados empresariais.
Serviços do COM+ para maior confiabilidade e 
escalabilidade. Internet Explorer fornece
D/HTML, melhorando interatividade. 
Introdução ao .NET 
Cenário ~2002 - Ubiqüidade
Navegadores
padrão
Clientes
“inteligentes”
Dispositivos
“inteligentes”
Protocolos públicos
de comunicação
(HTTP, SMTP, XML, SOAP) Ferramental mais
rico para o
usuário
Potencial para aplicações 
compostas por web 
services disponíveis 
globalmente
Aplicações podem se tornar Web services
Serviços
básicos
Lógica de
negócio
Lógica de 
negócio e Web 
services
Serviços
básicos
Web Services
públicos
Serviços
auxiliares
Serviços
internos
SGBD
Outros 
serviços
Protocolos de Internet
SOAP,
HTTP, SMTP, XML
Introdução ao .NET 
A Plataforma .NET
Arcabouço
.NET
Windows 
CE, 2000, XP, .NET
S
e
rv
iç
o
s
 
C
O
M
+
Orquestração
Aplicações
usando seus
serviços
Aplicações
para
usuário final
Servidores .NET
Serviços 
básicos .NET 
Web services
de terceiros
Seus serviços
internos
Visual 
Studio .NET
Sua aplicação
e web service
O Framework.NET
O que é?
• Um conjunto de tecnologias que:
– Une aplicações web hoje isoladas
– Torna informação disponível a qualquer hora, em 
qualquer lugar (anytime, anywhere)
– Simplifica desenvolvimento e implantação
O Framework.NET
O que é?
• Como o .NET faz isso?
– Web services
– Informações transitam como ADO.NET DataSets, 
havendo suporte a XML
– Conjunto rico de ferramentas, serviços para execução 
(runtime services) e implantação baseada em XCOPY
O Framework.NET
Web Services baseados em XML
• Ponto focal da arquitetura do .NET
• Trata-se de um componente de aplicação programável, 
acessível através de protocolos web padrão
• Expõe funcionalidade que pode ser acessada a partir de 
sites
– Possui semelhança com programação de componentes para uso 
na web, porém sem as dificuldades impostas pelo DCOM
O Arcabouço .NET
Visual Studio .NET
Base class library
Common language specification
Common language runtime
ADO.NET: Dados e XML
Visual Basic® C++ C#
V
is
u
a
l S
tu
d
io
®
 .N
E
T
ASP.NET: Web services
e Web Forms
JScript® …
Windows
Forms
O Framework .NET
Common Language Runtime
• Simplifica o desenvolvimento
• Implantação via XCOPY
• Potencialmente multi-plataforma
• Múltiplas linguagens (com herança entre 
linguagens)
• Aumenta a produtividade
O Arcabouço .NET
Serviços do Arcabouço
• ASP.NET
– Evolução do ASP (compilado)
• Web Forms
– Código gerenciado (mais elegante)
• Windows Forms
– Para desenvolvimento de interfaces para clientes ricos
• ADO.NET, evolução do ADO
– Novos objetos e maior suporte a trabalho desconectado
• Suporte a XML
Common Language Runtime
Arquitetura
C
o
m
m
o
n
 l
a
n
g
u
a
g
e
 r
u
n
ti
m
e
Class loader
IL para
compiladores
de código
nativo
GC, stack walk, code manager
Segurança
Suporte a 
execução
Common Language Runtime
Objetivos
• Desenvolvimento
– Framework com classes padrão
– Gerenciamento automático de memória
– Tratamento de erros consistente
– Aplicações multi-linguagem
– Múltiplas plataformas
– Execução mais segura
• Implantação
– Não há dependência do registry
– Menos problemas de versionamento
– Fim do “DLL Hell”
Common Language Runtime
Suporte a Múltiplas Linguagens
• Os tipos de dados foram unificados
– Common Type System (CTS)
• Outras linguagens e compiladores devem 
seguir a especificação...
– Common Language Specification (CLS)
Código fonte
C++, C#, Visual 
Basic ou 
qualquer outra 
linguagem .NET
Csc.exe, Vbc.exe,…
Compilador
Assembly
DLL ou EXE
Common Language Runtime
Compilação
Metadados
IL 
(código
gerenciado)
Recursos
MinhaBiblioteca.DLL
Common Language Runtime
Assemblies
Common Language Runtime
Metadados
• Informações de tipos
– Conjunto mais completo do que a IDL (da MS)
– Armazenadas no assembly em formato binário
– Descreve cada classe de tipo
– Usadas pelo IntelliSense® no
Visual Studio .NET
Descrições de tipos
Classes
Classes base
Interfaces Implementadas
Membros
Métodos
Nome
Versão
Cultura
Assembly Manifest
Outros assemblies
Permissões
Tipos exportadosCommon Language Runtime
Metadados em um Assembly
Common Language Runtime
Aplicações
• Um ou mais assemblies
• Resolução de assemblies
– Usando metadados
• local (recomendado)
• Global Assembly Cache (GAC)
• Aplicações diferentes podem usar diferentes 
versões de um assembly
– Mais fácil de atualizar
– Mais fácil de remover
Visual BasicCódigo 
Fonte
Compilador
C++C#
CompiladorCompilador
Assembly
Código em IL
Serviços básicos do SO
Common language runtime
Compilador JIT
Código nativo
Código
Gerenciado
Componente
não
gerenciado
Common Language Runtime
Modelo de Execução
Assembly
Código em IL
Assembly
Código em IL
Tipos de Aplicações
• Interface com o usuário
– Windows Forms
– ASP.NET Web Forms
• Camada de Negócio
– Serviços
– Componentes
• .NET Remoting
• Web Services
• Acesso a dados
– ADO.NET
Interface com o Usuário
Windows Forms
• Framework para implementação de clientes 
ricos
– RAD (rapid application development)
– Interfaces elaboradas
– Fácil integração com web services
– Conjunto extenso de controles
– Controles data-aware
– Compatível com ActiveX
Interface com o Usuário
ASP.NET Web Forms
• ASP.NET X ASP
– Código isolado de interface
– Compilado em DLL
– Escrito em qualquer linguagem que siga a CLS
– Performance melhorada
– Mais produtivo
• Desenvolvimento de interface para Windows Forms e Web 
Forms no mesmo IDE
• Manipulação de estado melhor do que no ASP
• Scripts de execução no cliente em JavaScript ou VBScript
• Extenso conjunto de controles no servidor, inclusive data-
aware
• Executa independentemente do ASP (pode haver integração, 
se desejado)
Camada de Negócio
Serviços
• São aplicações que executam independentemente de 
um usuário estar “logado”
• Desenvolvidos em qualquer linguagem que siga a CLS
• Exemplo: serviço de impressão
Camada de Negócio 
Componentes
• Utilizam-se do .NET Framework ao invés do 
COM
• Podem interoperar com componentes COM
• Podem utilizar os serviços do COM+
• Para sistemas distribuídos, existem dois tipos 
básicos de cenários
– Plataforma Homogênea: .NET Remoting
– Plataforma Heterogênea: Web Services
• Canais de comunicação podem utilizar um formato 
binário sobre TCP/IP ou ainda XML sobre HTTP
• Mensagens que transitam no canal de comunicação 
são codificadas
• Assim como no DCOM, existem proxies que remetem 
as chamadas de métodos ao objeto destino
• Ativação remota e gerenciamento de tempo de vida
– Marshal-by-reference: objetos executam no servidor
– Marshal-by-value: objetos executam em cópia realizada no 
cliente
Camada de Negócio 
.NET Remoting
Camada de Negócio 
Web Services
• São aplicações que disponibilizam funcionalidades 
acessíveis via Internet
– Baseado em SOAP/XML
• O cliente acessa através de URL
• Possui semelhanças com o uso de componentes 
distribuídos via Internet
• Por seguir padrões abertos, independe de plataforma
Acesso a Dados
Evolução do ADO para ADO.NET
• Novos objetos
• Maior suporte a XML
– Lê/escreve em arquivos XML
– Objetos para navegação em XML
– Permite uso de XSL
– Componentes sem estado podem devolver informações em XML
• Melhor isolamento de trabalho conectado ou desconectado
• Acesso a bases de dados
– .NET providers
– OLEDB providers
– ODBC
• Usa os mesmos tipos previstos no CTS
• http://msdn.microsoft.com 
• http://msdn.microsoft.com/howto
• http://www.microsoft.com/net
• http://www.microsoft.com/usa/webcasts
• http://msdn.microsoft.com/xml
• msnews.microsoft.com
– microsoft.public.dotnet.general
– microsoft.public.dotnet.xml
Referências
Exercícios
1. Cite as principais vantagens e desvantagens de 
cada arquitetura.
2. Explique as principais semelhanças e diferenças 
das duas arquiteturas.
3. As duas tecnologias realmente executam suas 
aplicações em diferentes sistemas operacionais.
4. Explique como é o desenvolvimento de software 
para a web usando uma destas arquiteturas.
Exercícios
5. Você foi designado pela sua empresa para 
escolher uma nova tecnologia para 
desenvolvimento da nova versão do software. A 
empresa está entre JEE e .NET. 
– Explique quais os critérios que você irá usar na 
escolha. 
– Explique a sua estratégia de testes nas duas 
plataformas. 
– Explique o impacto disto no desenvolvimento de 
software. 
– Explique o que significa ficar vinculado a uma 
tecnologia nos próximos anos.