Slides .pdf aulas de Engenharia de Software III

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

IES300_Aula07_DIAGRAMA_IMPLANTACAO.pdf
DIAGRAMA DE 
IMPLANTAÇÃO 
DIAGRAMA DE IMPLANTAÇÃO 
questão da organização da arquitetura física 
sobre a qual o software será implantado. 
 
máquinas (computadores pessoais, 
servidores etc.) que suportarão o sistema 
 como essas máquinas estarão conectadas 
protocolos se comunicarão 
distribuição dos módulos do sistema 
(executados em mais de um servidor) 
NÓS 
representar um item de 
hardware 
ambiente de execução (sistemas 
operacionais ou sistemas de 
banco de dados). 
NÓS 
ESTEREÓTIPOS 
<<device>> - dispositivo genérico 
<<computer>> - um computador 
mais simples 
<<secure>> - hardware de segurança 
<<server>> - servidor 
<<storage>> - hardware cuja função 
é armazenar informações 
ASSOCIAÇÕES 
 ligações físicas entre si de forma que possam se 
comunicar e trocar informações 
ARTEFATOS 
 é uma entidade física, um elemento concreto que 
existe realmente no mundo real (arquivo fonte, 
arquivo executável, arquivo de ajuda, documento 
de texto etc) 
Interface caixa 
Eletrônico Firewall Servidor 
Comunicaçaõ 
Gerenciador de 
Auto-atendimento 
SGBD 
Gerenciador 
de contas 
REFERÊNCIAS 
Guedes, Gilleanes T. A. UML 2: uma 
abordagem prática. 2.ed. São Paulo: 
Novatec Editora, 2011. 
 
IES300_Aula06_Diagrama_Sequência.pdf
DIAGRAMA DE SEQUÊNCIA 
DIAGRAMA COMPORTAMENTAL 
OBJETIVO 
 determinar 
 a ordem em que os eventos 
ocorrem 
 as mensagens que são enviadas 
 os métodos que são chamados 
 Como objetos interagem dentro 
de um determinado processo 
DIAGRAMA DE SEQUÊNCIA 
 BASEADO EM: 
 DIAGRAMA DE CASOS DE USO 
(PROCESSO) 
 DIAGRAMA DE CLASSES (OBJETOS) 
ATORES 
 representam entidades externas que 
interagem com o sistema e que solicitam 
serviços 
 instâncias dos atores declarados 
 no diagrama de caso de uso 
 Possuem uma linha de vida 
 
LIFELINES 
 Refere-se a uma instância de uma 
classe que participa de uma interação 
(objeto). 
 Possui uma linha de vida 
 
Pesfis1 : 
Pessoa_Física 
LIFELINES - Existência 
 desde o início do processo - aparece 
na parte superior do diagrama. 
 criado durante o decorrer da 
execução do processo - na mesma 
altura em que a mensagem que o criar 
for chamada. 
LINHA DE VIDA 
 representa o tempo em que um 
objeto existe durante um processo 
 interrompida com um "X" quando o 
objeto é destruído Pesfis1 : 
Pessoa_Física 
FOCO DE CONTROLE OU ATIVAÇÃO 
 Indica os períodos em que um 
determinado objeto está participando 
ativamente do processo. 
 representados dentro da linha de vida 
de um objeto por uma linha mais 
grossa 
Foco de Controle - Exemplo 
Pesfis1 : 
Pessoa_Física 
Consultar Cliente : 
Con_CPF(long) 
Dados Cliente : String Foco de 
Controle 
Linha de 
Vida 
MENSAGENS OU ESTÍMULOS 
 Demonstram a ocorrência de eventos 
 Pode ser disparadas entre: 
 um ator e outro ator 
 um ator e um objeto 
 um objeto e outro objeto 
 um objeto e um ator 
 Representadas por linhas entre dois 
componentes 
Consultar Cliente : con_CPF (long) 
Mensagens 
 A seta indica qual componente enviou a 
mensagem e qual a recebeu 
 A ordem sequencial é demonstrada de cima 
para baixo 
 Os textos contidos nas mensagens 
primeiramente identificam qual evento 
ocorreu e forçou o envio da mensagem e 
qual método foi chamado. 
 
Mensagem 
Cliente 
Funcionário 
Solicitar Abertura de Conta 
Descreve 
somente o 
evento 
Mensagens 
Pesfis1 : 
Pessoa_Física 
: Controlador Banco 
Consultar cliente : con_CPF(long) 
Mensagem 
Comun1 : 
Conta_Comun 
: Controlador Banco 
Abrir Conta (int) 
Mensagem 
caritm1: 
Item_Carrinho 
Excluir Item : Excluir() 
car1: 
Carrinho_Com 
Componente - Mensagens de 
retorno 
 Identifica a resposta a uma 
mensagem para o objeto ou ator que 
a chamou. 
 representadas por uma linha 
tracejada contendo uma seta fina e 
aponta para o objeto que recebe o 
resultado do método chamado. 
Mensagem de Retorno 
Pesfis1 : 
Pessoa_Física 
: Controlador Banco 
Consultar cliente : com_CPF(long) 
Dados cliente : String 
AutoChamadas ou Autodelegações 
 são mensagens 
que um objeto 
envia para si 
mesmo. 
Pesfis1 : 
Pessoa_Física 
ValCpf(String) 
Detalhes de Tempo 
 Definir detalhes de tempo de uma 
mensagem. 
 a mensagem é apresentada na 
diagonal 
Detalhes de Tempo 
 : Pedido 
: Controlador Vendas 
Cancelar_pedido() { 
mais de 20 minutos 
de espera } 
Mensagens Perdidas 
 É uma mensagem que foi enviada 
e sua confirmação de 
recebimento não foi recebida 
 mensagem não chegou ao seu 
destino 
 mensagem enviada a um destino 
não representado no diagrama 
Mensagens Perdidas 
: Receptor : Transmissor 
Mensagem_Envio() 
Mensagens Encontradas 
 representa o recebimento de uma 
mensagem: 
 enviada por um elemento desconhecido 
 Enviada por um elemento não 
representado no diagrama 
 recebimento de uma mensagem que 
fora dada como perdida pois seu tempo 
de espera por resposta poderia ter sido 
encerrado. 
 
Mensagens Encontradas 
: Receptor : Transmissor 
Mensagem_Resposta() 
Fragmentos de Interação 
 são noções abstratas de unidades de 
interação geral. 
 é uma parte de uma interação. 
 representado como um retângulo que 
envolve toda a interação e contém uma 
aba no canto superior esquerdo (operador 
que determina qual tipo de diagrama de 
interação se refere e a descrição da 
interação que está sendo modelada) 
sd indica que é um diagrama de sequencia 
Emitir saldo é o nome da interação que está sendo modelada 
Usos de Interação 
 Permite referenciar outros diagramas 
por meio do operador Ref (Referred - 
referido) 
 facilita leitura e compreensão 
 Permite a construção de diagramas mais 
complexos 
Usos de Interação 
Fragmentos Combinados 
 Permitem uma modelagem semi-
independente de parte do diagrama. 
 Trabalha questões como testes se-senão, laços 
ou processamentos paralelos. 
 Representados por um retângulo que 
determina a área de abrangência do 
fragmento no diagrama 
 Contêm uma subdivisão em sua extremidade 
superior esquerda para identificar a descrição 
do fragmento combinado e seu operador de 
interação. 
Operador de Interação - alt 
 Abreviatura de Alternatives (Alternativas). 
 define que o fragmento combinado 
representa uma escolha entre dois ou mais 
comportamentos. 
Operador de Interação - opt 
 Abreviatura de Option (Opção). 
 representa uma escolha de comportamento 
onde esse comportamento será ou não 
executado 
 
Operador de Interação - par 
 Abreviatura de Parallel (Paralelo). 
 representa uma execução paralela de dois ou 
mais comportamentos. 
Operador de Interação - loop 
 Abreviatura de Looping (Laço). 
 Representa um laço que
poderá ser repetido 
diversas vezes. 
Operador de Interação – Break 
(Quebra) 
 Indica uma "quebra" na execução normal do 
processo, usado para modelar o tratamento 
de exceções. 
 
Operador de Interação - Critical 
Region (Região Crítica) 
 identifica uma operação atômica que não 
pode ser interrompida por outro processo até 
ser totalmente concluída 
Invariante de Estado 
 é uma restrição de tempo de execução 
aplicada aos participantes da interação 
(valores de atributos ou variáveis, estados 
internos ou externos, etc) 
 deve ser colocado sobre uma linha de vida 
 condição deve ser avaliada durante o tempo 
de execução. 
 representado por um círculo posicionado 
sobre a linha de vida do elemento ou por um 
texto entre chaves 
REFERÊNCIAS 
 Guedes, Gilleanes T. A. UML 2: uma 
abordagem prática. 2.ed. São Paulo: Novatec 
Editora, 2011. 
 
IES300_Aula14_SOA.pdf
SOA 
SERVICE ORIENTED 
ARCHITECTURE 
 
ARQUITETURA ORIENTADA A SERVIÇOS 
 
SOA como estratégia competitiva 
visões abstratas de como o arquiteto deve 
modelar soluções de software 
Alinhamento entre o negócio e a 
TI 
Alinhamento entre o negócio e a 
TI 
 identificar as atividades de negócio 
 definir quais devem ser priorizadas e 
transformadas em serviços de TI 
Priorização 
 Prazo 
 Orçamento 
 disponibilidade de pessoal qualificado 
 apoio da alta gerencia 
Mapeamento 
 top-down (de cima para baixo ) 
 bottom-up (de baixo para cima) 
Abordagem top-down 
 partir de uma visão geral do seu 
domínio de negócio, a organização 
deve identificar os processos que lhe 
são prioritários e, a partir dessa 
enumeração, mapeá-los em serviços 
de TI. 
Abordagem bottom-up 
 identifica os ativos de TI disponíveis e, 
baseando-se nessa composição e 
disponibilidade de recursos, 
determina os tipos de serviços que 
será capaz de desenvolver e, só então, 
segue com a priorização dos 
processos de negócio que se ajustam 
a essa realidade. 
 
Perspectivas de arquiteturas 
orientadas a serviços 
 Perspectiva organizacional 
 criação de metodologias de 
mapeamento de processos 
corporativos 
 criação de políticas de alinhamento 
estratégico baseadas em serviços 
Perspectivas de arquiteturas 
orientadas a serviços 
 Perspectiva técnica 
 expandir a capacidade técnica para 
outras abordagens de 
desenvolvimento (arquiteturas 
orientadas a componentes ou 
arquiteturas orientadas a domínios 
de negócio) 
Ciclo de vida de soluções 
SOA 
 Planejamento 
 Desenvolvimento 
 Instalação 
 Manutenção 
 atividades necessárias para a condução e 
controle das atividades existentes em um 
desenvolvimento orientado a serviços 
Papéis 
 Consultor de negócios: que pode ser um agente 
externo ou interno à organização e que é o 
responsável por mapear os processos de negócio. 
 Arquiteto SOA: que utiliza as informações 
fornecidas pelo consultor de negócios para criar as 
soluções técnicas de infraestrutura e software. 
 Provedor: nesse caso, a organização em si, 
responsável por publicar o serviço interna 
(Intranet) ou externamente (Internet). 
 Cliente/consumidor: que utiliza o serviço por 
pontos de acesso descobertos em registros de 
publicação de serviços. 
 
Modelagem e planejamento do 
serviço 
 
 identificar os principais recursos 
necessários para a construção de 
novos serviços 
 reuso de serviços existentes 
 integração (coordenação) entre 
aqueles que compõem a solução de 
negócio. 
Desenvolvimento do serviço 
 levantamento de requisitos 
 Modelagem 
 projeto de construção 
 Teste 
 Manutenção 
 etc 
Instalação do serviço 
  Colocar o serviço em execução. 
 montagem da infraestrutura (máquinas, redes 
etc.) 
 configuração do ambiente (sistema 
operacional, banco de dados, servidor de 
aplicação) 
 instalação do serviço no servidor de aplicação 
 Testes 
 disponibilização interna (Intranet) ou externa 
(Internet). 
 
Publicação do serviço 
 
 o serviço deve ser publicado para que 
seja acessada pelo cliente 
 explicitar as regras de acesso e interação 
dos serviços 
 tecnologias utilizadas para a construção 
 responsáveis pelo serviço 
Descobrimento do serviço 
 
 identificar um serviço mediante 
seus atributos de negócio e/ou a 
tecnologia utilizada em sua 
construção 
Utilização do serviço 
 
 O cliente o utiliza seguindo as 
instruções fornecidas pelo 
registro de publicação. 
Composição do serviço 
  Agrupa-se serviços para criar funcionalidades 
semanticamente equivalentes aos processos 
de negocio. 
 Cada funcionalidade pode ser composta por 
um ou mais serviços dedicados ou 
compartilhados 
 Deve refletir características que possuam 
representações flexíveis das regras de 
negócio, automatizem o processo de 
composição baseado nas regras de negócio e 
representem processos de negócio válidos. 
 
Colaboração e orquestração 
entre serviços 
 
 Em um processo de negócio, diferentes 
tarefas devem colaborar para se alcançar o 
resultado esperado. 
Monitoramento e gerência da 
qualidade dos serviços 
 
 evitar que defeitos inertes ou 
problemas de desempenho afetem 
sua execução 
Controle de acesso 
 serviço deve oferecer algum tipo de 
mecanismo de controle de acesso 
para que seja possível identificar 
quem acessou o serviço em processos 
de auditoria e para evitar o uso 
indevido por clientes mal-
intencionados 
Monitoramento do desempenho 
 melhoria técnica da infraestrutura e 
desenvolvimento 
 economia de tempo e gastos 
 aumento da capacidade de identificação de 
problemas 
 registro de defeitos e falhas para avaliação 
do processo de desenvolvimento 
 análise dos dados e da informação 
referentes ao uso dos serviços. 
 
Negociação em nível de serviço 
(Service Level Agreement - SLA) 
ou contrato de uso 
 define a forma como o cliente e o 
provedor devem se comportar para 
que haja o provimento do serviço 
Governança dos serviços 
 
 determina o comportamento 
esperado de todos os atores 
envolvidos no processo de construção 
de soluções SOA. 
 determina o processo de gestão das 
atividades que compõem seu ciclo de 
vida. 
Arquitetura de referenda SOA 
(Reference Architecture - SOA-RA) 
 responsáveis por fornecerem os 
mapeamentos dos processos de 
negócio e os requisitos técnicos para 
o uso dos padrões e ferramentas 
envolvidas em seu processo de 
modelagem e construção 
Elementos - arquitetura de 
referência 
 
SOA 
Domínio 
de 
Negócio 
Soluções 
Tecnológicas 
Governança 
Arquitetura 
de 
Informação 
Domínio de negócio 
 influencia na identificação das 
estratégias, objetivos e prioridades de 
negócio. Conceber um modelo de 
negócio correto é essencial para a 
implementação de soluções de TI de 
sucesso. 
Soluções tecnológicas 
 representa o conjunto de padrões e 
ferramentas que farão parte da 
infraestrutura de SOA. 
 
Arquitetura de informação 
 gera insumo para o processo de 
modelagem e projeto e que, por sua 
vez, afeta a construção da solução 
Governança 
 identificar
as responsabilidades, 
direitos e deveres dos atores 
envolvidos na construção de soluções 
SOA é essencial para a concepção de 
soluções verdadeiramente alinhadas 
aos negócios 
Modelo de maturidade para 
SOA 
  reflete as proficiências de negócio e 
técnica disponíveis para a concepção de 
soluções. 
 Cada nível define uma graduação em 
relação a capacidade da organização 
(física, as competências, habilidades e 
atitudes de seus colaboradores) baseada 
em processos mais ou menos avançados e 
experimentados. 
Nível 1 - Processo de 
desenvolvimento tradicional 
 determina um processo de 
desenvolvimento que não utiliza uma 
abordagem orientada a serviços como 
modelo de solução tecnológica. Nesse 
nível, a organização não está interessada 
em utilizar soluções SOA como estratégia 
de alinhamento. 
Nível 2 - Processo de 
desenvolvimento orientado a 
serviços, apoiado por soluções de 
TI simples 
 determina um processo de desenvolvimento 
SOA apoiado por soluções e serviços Web 
dentro de uma arquitetura composta por 
serviços simples sem a colaboração esperada 
em soluções de grande porte (sincronismo de 
dados, serviços de autenticação e 
funcionalidades simples) 
Nível 3. Processo de 
desenvolvimento orientado a 
serviços, apoiado por soluções de 
TI compostas 
 determina um processo de 
desenvolvimento SOA apoiado pela 
colaboração e orquestração de sistemas e 
serviços de TI que interagem para fornecer 
soluções lógica e semanticamente 
complexas 
Nível 4 - Processo de automação 
do negócio pelo uso de soluções 
de TI compostas 
 determina um processo de 
desenvolvimento onde a organização 
utiliza todo o potencial fornecido 
pelas soluções orientadas a serviços 
compostas para automatizar e 
otimizar o alinhamento estratégico 
entre a TI e o negócio 
Elementos de uma arquitetura 
de referência 
 
 Camada Web (ou cliente) - determina 
que todos os serviços sejam 
acessados por aplicações e clientes 
Web. Normalmente, isso ocorre pelo 
uso do protocolo HTTP ou HTTPS 
para acesso aos serviços. 
 
Elementos de uma arquitetura 
de referência 
 Camada de serviço: determina a camada 
em que os serviços são publicados no 
registro, acessados via barramento e 
gerenciados pelo orquestrador. Viabiliza os 
mecanismos de integração e colaboração 
e fornece a infraestrutura necessária para 
a criação das soluções de negócio 
mediante a formação dos grupos 
semânticos dos serviços de TI. 
 
Elementos de uma arquitetura 
de referência 
 Camada de negócio: essa camada pode 
ser vista como aquela que tem os 
componentes que contêm as regras de 
negócio. Normalmente, são desenvolvidas 
em JEE e acessadas local ou remotamente 
pelos serviços. 
 
Governança de SOA 
 subconjunto dos elementos que 
compõem a teoria de governança de 
TI (GTI). 
 Programas (ou modelos) de 
governança de SOA buscam 
regulamentar a gestão dos processos 
e atividades que compõem o ciclo de 
vida de soluções orientadas a 
serviços. 
Governança de SOA 
 uma técnica para ajudar a 
organização a implementar os 
mecanismos de controle mais 
eficientes e seguros, especificamente 
focados no desenvolvimento de 
soluções orientadas a serviços. 
 
Perspectivas de governança 
de SOA 
  Governança do provedor: define 
responsabilidades, políticas, padrões, 
normas e procedimentos que serão 
utilizados para desenvolver e publicar 
os serviços 
Perspectivas de governança 
de SOA 
 Gerência do provedor: define as atividades 
que devem ser conduzidas para manter o 
alinhamento necessário entre os processos 
de desenvolvimento e as normas de 
governança. 
 
Perspectivas de governança 
de SOA 
 Governança do consumidor: define quem 
deve aceitar e obedecer as regras e 
responsabilidades, políticas, padrões, normas 
e procedimentos de localização e uso dos 
serviços. 
 
Perspectivas de governança 
de SOA 
 Gerência do consumidor: define as 
atividades que devem ser conduzidas 
por quem cumpre as regras de 
alinhamento entre os processos de 
localização e uso do serviço. 
 
 a visão de governança é responsável 
por definir as regras do jogo 
 visão de gerência é responsável por 
colocá-las em prática 
Ciclo de vida de Governança SOA – 
Estabelece padrões das atividades 
Definição da estratégia 
 estabelecer a direção estratégica que 
irá seguir para a concepção das 
soluções orientadas a serviços. 
 identificados e priorizados os 
processos de negócios e os recursos 
de TI que serão usados para a 
construção dos serviços 
Desenvolvimento e Instalação 
 
Gerência de mudança e controle 
de versão 
 
 Corretiva: a mudança corretiva acontece quando falhas, defeitos ou 
erros são encontrados e o sistema precisa ser alterado para que o 
problema seja sanado. 
 Evolutiva: a mudança evolutiva acontece quando há a solicitação de 
novas funcionalidades. Nesse ponto, todo o processo de planejamento, 
definição, implementação e avaliação deve ser retomado para que o 
serviço mantenha seu padrão de qualidade. 
 Adaptativa: a mudança adaptativa acontece quando há uma alteração 
de ambiente e infraestrutura. É comum vermos constantemente o 
lançamento de novas versões de hardware e software; dentro desse 
contexto, a organização deve se preparar para adaptar seus serviços ser 
uma evolução tecnológica, que lhe pareça pertinente, ocorra. 
 
Migração 
 
 tenta criar um ambiente em que o processo 
de mudança ocorrido em momentos de 
desativação e ativação de serviço não 
causem danos na relação entre organização e 
cliente 
 
Publicação e Registro 
 
 Criar regras para a publicação dos serviços, a 
organização consegue rastrear o impacto e 
minimizar os problemas por meio de ações 
objetivas e específicas para cada cliente. 
Monitoramento e comunicação 
 
 Influenciam no controle das evoluções de 
software que são utilizadas para a criação 
dos serviços 
 Influenciam no controle das evoluções de 
infraestrutura utilizada para executar os 
serviços 
 Influenciam no processo de negociação 
entre o cliente e a organização 
Monitoramento e comunicação 
 
 Manter um registro regular das 
atividades de um projeto ou 
programa 
 Capaz de detectar falhas antes que 
ocorram 
Teste e manutenção 
 Teste de Unidade 
 Integração 
 Validação 
 Sistema 
 Recuperação 
 Segurança 
 Estresse 
 Desempenho 
Segurança - Identificação 
dos ativos de informação 
  define o que deve ou não ser protegido. É 
fruto das regras de negócio e produzido pela 
organização. 
 
Segurança - Identificação 
dos responsáveis pela 
informação 
  aqueles que criam ou utilizam a 
informação em benefício próprio devem 
ser os responsáveis por definir os critérios 
de autorização para uso e distribuição da 
informação. 
 
Garantia de 
confidencialidade 
  garante que a informação só está 
acessível para quem tem o nível de 
autorização correto. 
 
Segurança - Disponibilidade 
 atribuição adequada das autorizações 
de acesso, ou seja, garantir que quem 
pode acessar a informação possua o 
nível de segurança adequado. 
 
Segurança - Garantia de 
Integridade 
  ter a certeza de que as 
informações utilizadas estão 
consistentes e representam a 
verdade. 
 
Segurança - Vulnerabilidade
 identificar e solucionar os fatores que 
podem ser explorados e transformados em 
uma ameaça. Além de se preocupar com a 
segurança física, a organização deve incluir 
no acordo de uso do serviço as regras e 
atividades que são desempenhadas para 
identificação e solução de 
vulnerabilidades. 
 
Referencias 
 Marzullo, Fabio Perez. SOA NA PRÁTICA: 
inovando seu negócio por meio de soluções 
orientadas a serviços. São Paulo: NOVATEC 
Editora, 2009. 
 Sommerville, Ian. Engenharia de Software. 9. 
Ed. São Paulo, Pearson Prentice Hall, 2011. 
 Pressman, Roger S. Engenharia de Software: 
uma abordagem profissional. 7. ed. Porto Alegre: 
AMGH (Mc Graw Hill), 2011. 
 Vantagens e Desvantagens de 
SOA http://www.devmedia.com.br/vantagens-
e-desvantagens-de-soa. acessado em 01/07/2013 
 
IES300_Aula13_SOA.pdf
SOA 
SERVICE ORIENTED ARCHITECTURE 
 
 
ARQUITETURA ORIENTADA A SERVIÇOS 
 constantes evoluções na forma como são 
conduzidos projetos de software e a construção 
de sistemas 
HISTÓRICO 
mudanças são reflexos do comportamento volátil que 
os ambientes de negócios 
desenvolver sistemas mais flexíveis e ágeis, com alta 
capacidade de customização, 
HISTÓRICO 
 Alexander Pasik, em 1994 do Grupo Gartner. 
 
 
 
 
 Estudos da Microsoft, IBM e outras empresas 
em 2000 sobre a tecnologia Web Services. 
SOA - Objetivos 
 Integrar aplicações 
 Disponibilizar maior flexibilidade para 
mudanças 
 Suportar serviços independentes de 
plataformas e protocolos 
SERVIÇOS 
 um conjunto de atividades correlatas, com 
objetivo ou regras bem definidos, e que, ao 
ser avaliado no todo, representa um benefício 
de valor específico para o qual se deseja um 
controle de recursos consumidos (também 
denominado ativos). Assim um Serviço pode 
ser visto como uma ou mais ações com um 
dado fim." 
 
SERVIÇO 
 É um tipo de relacionamento (contrato) entre 
um provedor e um consumidor, sendo que esse 
provedor se compromete em realizar 
determinadas tarefas com resultados pré-
estabelecidos para um consumidor, e que, por 
sua vez, se compromete a usar o serviço da 
forma contratada." 
 
IEEE 
SERVIÇOS 
 Uma função de transformação da informação 
necessária ao negócio. Essa função será um 
serviço se puder ser mapeada em atividades 
repetíveis. 
SERVIÇOS 
 Serviços são módulos de negócio ou 
funcionalidades que possuem interfaces 
expostas que são invocadas via 
mensagens. Interfaces disponibilizam 
recursos sem que a implementação do 
serviço seja conhecida. 
 
 
PRINCÍPIOS DE DESIGN DE 
SERVIÇOS (Thomas ERL(2009)) 
 Serviços são reutilizáveis. 
 Serviços compartilham um contrato formal. 
 Serviços possuem um baixo acoplamento. 
 Serviços abstraem a lógica. 
 Serviços são capazes de se comporem. 
 Serviços são autônomos. 
 Serviços evitam alocação de recursos por longos 
períodos. 
 Serviços são capazes de serem descobertos. 
 
 
AMBIENTE DE PRESTAÇÃO DE 
SERVIÇOS 
Ambiente de negócio 
Provedor (aquele que 
fornece o serviço 
Consumidor(aquele 
que utiliza o serviço Interação 
SERVIÇOS - ELEMENTOS 
 o propósito do serviço; 
 os atores que estão envolvidos na 
prestação e no consumo do serviço; 
 a informação que é trocada por ambas as 
partes; 
 os processos ou atividades que são 
representados pelo serviço, e 
 os recursos necessários para a execução 
do serviço. 
 
SERVIÇOS 
 Representado como uma composição de 
diferentes elementos 
 
 
 
 Serviço= {Entradas, Saídas, Objetivos, 
Transformações, Recursos, Sensores} 
 
Entradas 
 representam as informações enviadas pelo 
consumidor 
Saídas 
 representam as informações devolvidas para 
o consumidor pelo provedor de serviço; 
 
Objetivos 
 representam as regras de negócio abrangidas 
pelo serviço 
 
Transformações 
 representam a aplicação dessas regras às 
informações de entrada, o que gera as 
informações de saída 
Recursos 
 Representam os elementos utilizados pelo 
serviço durante sua execução 
 
 pessoas (clientes, consultores, parceiros, 
etc.); 
 informações (essenciais ou auxiliares); 
 processos (processos, subprocessos, 
atividades, tarefas); 
 infraestrutura (máquinas e material de 
apoio). 
 
Sensores 
 representam os elementos de sistema que 
monitoram, detectam mudanças do seu 
ambiente de execução e respondem de 
acordo. 
 
SERVIÇOS - TIPOS 
 Serviços gratuitos 
 Serviços pagos 
 Serviços de governo 
Serviços gratuitos 
 são contratados sem a necessidade de se 
pagar pelo seu provimento (Serviços de e-
mail gratuitos. 
Serviços pagos 
 
 são aqueles que requerem uma taxa de 
utilização, sejam pré-pagos ou pós-pagos. 
(serviços na telefonia) 
Serviços de governo 
 
 são os que podemos chamar de serviços 
híbridos. São gratuitos em sua prestação, 
mas são fundamentalmente "patrocinados" 
pelo meu, o seu, o nosso imposto de cada 
dia. 
 
SERVIÇO DE TI 
 Representação lógica de uma atividade de 
negócio que pode ser mapeada por meio de 
uma entrada, um processamento e uma saída 
SERVIÇO DE TI 
 Representa um conjunto explícito e 
detalhado das tarefas necessárias para 
executar uma determinada atividade dentro 
de um processo existente na organização 
 operacionalmente independente, sempre 
fornecendo os mesmos resultados a partir de 
entradas iguais 
 pode ser composto por serviços distintos 
SERVIÇO DE TI 
 Mantém: 
 1) a atomicidade da operação 
 2) a consistência das informações 
 3) o isolamento e a independência 
necessários para a composição do serviço 
 4) eventualmente a persistência dos 
resultados. 
 
SOA (Service Oriented Architecture) 
 Uma forma de desenvolvimento de 
sistemas distribuídos em que os 
componentes de sistema são serviços 
autônomos, executando em 
computadores geograficamente 
distribuídos 
SOA 
 Uma nova abordagem para a utilização de 
recursos de TI em apoio ao negócio da 
organização. 
SOA 
 Modelo de Planejamento de estratégia da 
área de TI, alinhando diretamente aos 
objetivos de negócios de uma organização 
Avellar e Duarte , 2012 
SOA - Vantagens 
 Reutilização: O serviço pode ser reutilizado para 
outras aplicações. 
 Produtividade: Com o reuso, a equipe de 
desenvolvimento pode reutilizar serviços em 
outros projetos, diminuindo o tempo de 
desenvolvimento. 
 Flexibilidade: Isolando a estrutura de um serviço 
as mudanças são feitas com maior facilidade. 
 
 
SOA - Vantagens 
 Manutenibilidade: Com baixo acoplamento, 
facilita a manutenção dos serviços. 
 Alinhamento com o negócio: A área de 
negócio visualiza os processos alinhados com 
a tecnologia. 
 Interoperabilidade: Disponibilizar serviços 
independentemente da plataforma e 
tecnologia. 
 
 
SOA - Vantagens 
 Integração: A integração com outros 
serviços, aplicativos e sistemas legados. 
 Governança: Gerenciamento nos 
processamentos de negócio. 
 Padronizado: É baseado no uso de padrões. 
 Abstração: Serviço totalmente abstraído da 
sua implementação. 
 
 
SOA - Desvantagens
 Complexidade: Uma grande quantidade de 
serviços precisa ser gerenciada. 
 Performance: A performance depende do 
servidor onde o serviço está publicado, como 
também da rede. 
 Robustez: Caso uma exceção acontecer não 
tem como reverter o processo. 
 
 
SOA - Desvantagens 
 Disponibilidade: Uma queda na rede ou no 
servidor deixa todos os serviços indisponíveis. 
 Testabilidade: O debug no serviço é um 
problema para os desenvolvedores. 
 Segurança: Os serviços estão disponíveis na 
rede, qualquer aplicativo pode consumir esse 
serviço, os dados são trafegados pela rede 
podendo ser interceptados. 
 
 
Padrões para SOA 
 SOAP 
 WSDL 
 WS-BPEL 
 
SOAP (Simple Object Access 
Protocol) - Protocolo Simples de 
Acesso a Objetos 
 Padrão de troca de mensagem que 
oferece suporte à comunicação entre 
os serviços. 
 Define os componentes essenciais e 
opcionais das mensagens passadas 
entre serviços 
WSDL - Web Services Description 
Language 
 Linguagem de definição de Web-
Services. 
 Padrão para a definição de interface 
de serviço. 
 Define como operações de serviços e 
associações de serviços devem ser 
definidas 
WS-BPEL - Business Process 
Execution Language 
 Padrão para uma linguagem de 
workflow usada para definir 
programas de processo que envolvem 
vários serviços diferentes 
SOA 
 Desvincular o domínio de negócio de 
tecnologias e modelos específicos 
Acompanhar as mudanças exigidas 
Modelo Operacional Triangular 
SOA 
Registro 
Consumidor Provedor Execução 
Provimento do serviço 
 Determina o comportamento daquele que 
está disponibilizando o serviço (dono do 
serviço) 
 Fornece toda a infra-estrutura de acesso (via 
rede) 
 Capaz de responder a requisições internas 
(intranet) e externas (internet) 
Consumo do serviço 
 Determina o comportamento daquele que 
representa o cliente da organização 
provedora do serviços. 
 Poder ser uma pessoa, uma organização,uma 
máquina ou um componente de software. 
Registro do serviço 
 Comportamento que a organização deve ter 
para divulgar ser serviço e o do cliente que 
deve proceder para localizar o serviço 
desejado. 
 Responsável por gerenciar os repositórios que 
armazenam informações sobre os serviços e 
organizações que os fornecem. 
Engenharia de serviços 
 Identificação de serviço candidato (possíveis 
serviços que podem ser implementados e 
define os requisitos de serviço) 
 Projeto de serviço (projeta a lógica e as 
interfaces de serviço WSDL) 
 Implementação e implantação de serviço 
Identificação de serviço 
candidato 
 Compreensão e análise dos processos de 
negócios. 
Serviço utilitário (implementam funcionalidade 
geral). (conversor de moedas) 
Serviços de negócios (associado a uma função 
específica do negócio) – (registro de alunos em 
um curso) 
Serviços de Coordenação ou de processos – 
suportam um processo de negócio mais amplo, 
envolve atividades e atores diferentes – serviço 
de pedido 
 
Governança corporativa 
 Define a ideia de quem controla a 
corporação e por quê. 
 Foca nos papéis e responsabilidades 
daqueles que são os donos do negócio 
(comandam a organização). 
 
Governança corporativa 
 Criar estruturas que determinem os objetivos 
organizacionais e monitorem o desempenho 
para assegurar a concretização desses 
objetivos. 
Identificar o comportamento desejado 
Identificar os papéis e responsabilidades de 
cada setor da organização 
identificação de eventuais 
desvios de conduta 
Governança de TI 
 corresponde aos direitos decisórios e o 
modelo de responsabilidades que encorajam 
os comportamentos adequados no uso da TI. 
 
 Reflete os princípios gerais da governança 
corporativa enquanto se concentra no 
gerenciamento dos recursos e ativos de TI 
para atingir as metas de negócio da 
organização 
GOVERNANÇA DE TI 
 Entender como a TI é governada e saber 
como alinhar e integrar seus serviços no 
cumprimento dos objetivos de negócio são 
os principais indicadores de sucesso 
Estrutura Geral das Corporações Modernas 
GOVERNANÇA DE TI 
 Como as decisões de TI devem ser 
conduzidas? 
 Quem deve tomá-làs? 
 Quem possui o conhecimento para garantir 
adequação às necessidades da organização? 
 Como monitorar as decisões? 
 Quem deve ser responsabilizado pelas 
decisões tomadas? 
 
Decisões Chave 
 Princípios de TI: esclarecem o papel da TI nos negócios. 
 Arquitetura de TI: define os requisitos de integração e 
padronização. 
 Infraestrutura de TI: determina os serviços que darão 
suporte aos negócios. 
 Necessidade do negócio: especifica a necessidade 
comercial das aplicações de TI, comprada ou desenvolvida 
internamente. 
 Investimentos e priorização de TI: escolhem quais 
iniciativas de TI devem ser financiadas e quanto deve ser 
gasto em cada uma. 
 
MODELOS DECISÓRIOS 
 Monarquia de negócio: altos gerentes 
compõem o conselho, no qual todas as 
decisões são tomadas, inclusive as de TI. 
 Monarquia de TI: os especialistas de TI são 
responsáveis pela definição das cinco 
decisões-chave. 
 Feudalismo: cada unidade de negócio tem 
seu próprio comitê decisório; as unidades 
são independentes entre si. 
 
MODELOS DECISÓRIOS 
 Federalismo: constitui uma combinação 
entre o centro corporativo e as unidades de 
negócios, com ou sem o envolvimento do 
pessoal de TI. 
 Duopólio de TI: o grupo de TI e algum outro 
grupo (por exemplo, a alta gerência ou os 
líderes das unidades de negócios). 
 Anarquia: tomada de decisões individual ou 
por pequenos grupos de modo isolado. 
CICLO DE ALINHAMENTO 
ESTRATÉGICO DA TI 
FASE DE INICIAÇÃO 
Definir metas e objetivos da organização 
necessidades de negócio da organização 
priorizadas de acordo com o interesse da 
alta administração 
ALINHAMENTO ESTRATÉGICO 
 Colocar em práticas as atividades de TI que 
visam atender as necessidades da 
organização. 
Competências de negócio e 
estratégicas 
 domínio do negócio 
 essenciais no planejamento de estratégias, 
pois ajudam a entender as reais 
necessidades de negócio e facilitam o 
alinhamento dos serviços de TI com as 
metas da organização. 
 
Competências em CRM (Customer 
Relationship Management) e ERM 
(Employee Relationship Management): 
 melhorar o relacionamento entre 
organização e clientes 
Competência em terceirização 
 ajuda a reduzir os custos do desenvolvimento 
de sistemas e serviços de TI 
 garantir que os padrões definidos pela 
organização sejam seguidos e que os 
produtos gerados por essas parcerias estejam 
alinhados com as necessidades da 
organização. 
 
Competências de TI 
 relacionados à estrutura da TI, como 
infraestrutura, arquitetura, padrões de 
projetos, normas internacionais, modelos 
de maturidade, padrões de programação 
etc. 
 
Competências em integração 
de serviços 
 identificação de estratégias de 
alinhamento entre a modelagem de 
negócio e os serviços de TI. 
 A integração proporciona a padronização 
entre os sistemas, diminui os custos e 
ajudam no cumprimento das metas 
 
Competências em análise de 
desempenho 
 capacidade de se diagnosticar o real 
valor agregado à organização
em 
relação ao capital investido 
Competências em contratação 
 competências em contratação são 
importantes principalmente para 
organizações que têm o hábito de 
terceirizar seus serviços de TI e 
prestam serviços para o governo 
Referências 
 Marzullo, Fabio Perez. SOA NA PRÁTICA: 
inovando seu negócio por meio de soluções 
orientadas a serviços. São Paulo: NOVATEC 
Editora, 2009. 
 Sommerville, Ian. Engenharia de Software. 9. 
Ed. São Paulo, Pearson Prentice Hall, 2011. 
 Pressman, Roger S. Engenharia de Software: 
uma abordagem profissional. 7. ed. Porto Alegre: 
AMGH (Mc Graw Hill), 2011. 
 Vantagens e Desvantagens de 
SOA http://www.devmedia.com.br/vantagens-
e-desvantagens-de-soa. acessado em 01/07/2013 
 
IES300_Aula07_Diagrama_Atividades.pdf
DIAGRAMA DE ATIVIDADE 
DIAGRAMA DE ATIVIDADE 
 enfatiza a sequência e condições para 
coordenar comportamentos de baixo nível. 
 maior ênfase ao nível de algoritmo da UML . 
DIAGRAMA DE ATIVIDADE - 
Objetivo 
 modelar atividades, que podem ser um 
método ou um algoritmo, ou mesmo um 
processo completo. 
DIAGRAMA DE ATIVIDADE 
DESCREVE: 
 
 computação procedural (métodos) 
 modelagem organizacional (engenharia de 
processos de negócios e workflow). 
 modelagem de sistemas de informação para 
especificar processos ao nível de sistema. 
DIAGRAMA DE ATIVIDADE 
 Composta de um conjunto de ações (passos 
necessários para que atividade seja 
concluída). 
 
 
Atividade 
Representação 
Emitir Saldo 
 
Especifica a coordenação de execuções de 
comportamentos subordinados usando 
um modelo de fluxo de controle e dados. 
outros comportamentos no modelo 
terminarem sua execução 
devido a objetos e dados tornarem-se 
disponíveis 
ocorrência de eventos externos. 
Nó de Ação 
 representa um passo, uma etapa que deve ser 
executada em uma atividade. 
 é atômico (não podendo ser decomposto) 
 
Receber 
nro da 
conta 
Fluxo de Controle 
 conector que liga dois nós, enviando sinais de 
controle. 
Receber nro da 
conta 
Consultar 
conta 
Nó Inicial 
 representar o início do fluxo quando a 
atividade é invocada 
Receber nro da 
conta 
Consultar 
conta 
Nó Final 
 Representar o fim do 
fluxo de uma atividade. 
Receber nro da 
conta 
Consultar 
conta 
Apresentar 
saldo 
Nó de Decisão 
 representa uma escolha entre dois ou mais 
fluxos possíveis. 
 Em geral é acompanhado por condições de 
guarda ( textos entre colchetes que 
determinam a condição para que um fluxo 
possa ser escolhido). 
 
Nó de Decisão 
Consultar 
conta 
Solicitar Senha 
Receber 
nro da 
conta 
Consultar 
conta 
Act Emitir Saldo 
Solicitar 
Senha 
Receber 
Senha 
Act Emitir Saldo 
Consultar 
saldo 
Apresentar 
Saldo 
Validar 
Senha 
Nó de Bifurcação 
 nó de controle que permite dividir um fluxo 
em dois ou mais fluxos concorrentes 
Receber 
Pedido 
Atender 
Pedido 
Enviar 
Fatura 
Nó de União 
 nó de controle que permite mesclar dois ou 
mais fluxos concorrentes em um único fluxo de 
controle. 
Imprimir 
cartão de 
embarque 
Receber 
Bagagem e 
Imprimir 
Recibo 
Fprnecer Doctos 
de viagem para 
o passageiro 
Final de Fluxo 
Representa o 
encerramento 
de uma rotina 
representada 
pelo fluxo, mas 
não de toda a 
atividade. 
 
 
Instalar 
compone
nte 
Construir 
componente 
Nó de Objeto 
 representa uma instância de uma classe, que 
pode estar disponível em um determinado 
ponto da atividade. 
: Pedido 
Exemplo 
Atender 
Pedido 
Enviar 
pedido 
: Pedido 
Atualiza-se um 
objeto da classe 
pedido – Pino 
indenpendente 
Pins (alfinetes) 
 São nós de objeto que representam uma 
entrada para uma ação ou uma saída de uma 
ação. 
 Fornecem valores para as ações e recebem os 
valores resultantes delas. 
Atender 
Pedido 
Enviar 
pedido 
Pedido Pedido 
Nó de Parâmetro 
 É um nó de objeto utilizado para representar 
a entrada ou a saída de um fluxo de objetos 
em uma atividade 
Nó de Parâmetro 
: Matéria 
Prima 
: MP 
Aprovada 
: MP 
Rejeitada 
Validar 
acidez 
Exceções 
 Detalha a ocorrência de exceções 
ação 
Manipulador de 
Exceção 
Fluxo de Interrupção 
Nó de entrada de exceção 
Ação de Envio de Sinal 
 representa o envio de um sinal para um 
objeto ou ação. 
Verificar se a impressora 
está preparada 
Ação de evento de aceitação 
 Representa a espera de ocorrência de um 
evento de acordo com determinadas 
condições. 
Preparar texto 
para impressão 
Verificar se a 
impressora está 
preparada 
: Impressora 
Enviar texto para 
impressão 
Ação de Evento de Tempo de 
Aceitação 
  É uma variação da ação de evento de 
aceitação que leva em consideração o tempo 
para que o evento possa ser disparado. 
Realizar 
backup 
automático 
Final do Expediente 
Nó de Repositório de Dados (Data 
Store Node) 
 
 é usado para armazenar dados ou objetos 
permanentemente. 
Registrar novo 
cliente 
<<datastore>> 
Clientes 
Conectores 
 São atalhos para o fluxo ( quando existe uma 
distância relativamente grande entre os nós 
que o fluxo precisa ligar). 
ação A 
A 
Ação 1 
Ação de Chamada de 
Comportamento 
 é uma ação que invoca a execução de um 
comportamento (em geral uma atividade). 
Escolher 
Menu 
Escolher 
Item Menu 
: Confirmar 
pedido 
act Confirmar Pedido 
Fornecer 
Detalhes do 
Pagto 
Fornecer 
Detalhes da 
entrega 
Ação de Chamada de Operação 
 é uma chamada indireta a um 
comportamento, na qual é invocada a 
execução de uma operação (método) em 
um objeto de uma classe 
Abertura de Conta: 
abrir_conta 
(Conta_Comun::abrir_conta) 
Chamada de Operação 
método 
Classe que possui o método Nome de Operação 
Partição de Atividade 
 permitem representar o fluxo de um processo 
que passa por diversos setores ou 
departamentos de uma empresa, ou mesmo 
um processo que é manipulado por diversos 
atores. 
Receber 
Pedido 
Atender
Pedido 
Enviar 
Pedido 
Fechar 
Pedido 
Enviar 
Fatura 
Receber 
Pagto 
: Fatura 
Realizar
Pagto 
Região de Atividade 
Interrompível 
 engloba certo número de elementos da 
atividade que podem sofrer uma interrupção, 
não importando em que elemento da 
atividade a interrupção ocorra. 
Receber 
Pedido 
Atender
Pedido 
Enviar 
Pedido 
Fechar 
Pedido 
Enviar 
Fatura 
Receber 
Pagto 
: Fatura 
Realizar
Pagto 
Cancelar 
Pedido 
Região de Expansão 
 é um a região de atividade estruturada que é 
executada múltiplas vezes de acordo com os 
elementos de uma coleção de entrada. 
Receber fatorial a 
calcular 
Apresentar resultado 
do fatorial 
Calcular Fatorial 
<<Iteratives>> Cálculo do fatorial 
Referências 
 Guedes, Gilleanes T. A. UML 2: uma 
abordagem prática. 2.ed. São Paulo: Novatec
Editora, 2011. 
IES300_Aula02_Arquitetura_Introducao.pdf
ARQUITETURA DE 
SOFTWARE 
“O milagre mais comum da 
engenharia de software é a 
transição da análise para o 
projeto e do projeto para o 
código”. 
Richard Dué. 
CARACTERÍSTICAS DO SOFTWARE 
 Invisibilidade – Software é invisível e 
invisualizável 
Complexidade - Software é mais complexo do 
que qualquer outro produto construído por 
seres humanos 
Mutabilidade – Existe sempre uma pressão 
para se fazer mudanças em um software 
Conformidade – O software deve ser 
desenvolvido conforme o ambiente. Não é o 
ambiente que deve se adaptar ao software. 
Brooks, F. No Silver Bullet) 
INTRODUÇÃO 
Aumento do tamanho 
Aumento da complexidade 
Maior confiabilidade 
Bom desempenho 
Menor custo 
Demanda por Sistemas de 
arquitetura 
do sistema 
PROJETO 
 Cria uma representação ou 
modelo do software 
MODELO DE ANÁLISE (REQUISITOS) 
Concentra na descrição do 
"O que" é para ser feito 
 
dados 
função 
comportamento 
MODELO DE PROJETO 
Indica "O Como" fazer 
arquitetura de software 
fornecendo detalhes 
estruturas de dados 
interfaces 
componentes 
fundamentais 
para 
implementar 
o sistema 
PROJETO 
Permite que se modele o sistema ou 
produto a ser construído. 
 
O modelo pode ser avaliado em 
termos de qualidade e aperfeiçoado 
ANTES de o código ser gerado, ou de 
os testes serem realizados, ou de os 
usuários finais se envolverem com 
grandes números. 
 
PROJETO 
 É o lugar onde a qualidade do 
software é estabelecida. 
 
PROJETO - ETAPAS 
Representar a arquitetura do sistema 
ou do produto. 
Modelar as interfaces que conectam o 
software aos usuários finais a outros 
sistemas e a dispositivos, bem como 
seus próprios componentes internos. 
Projetar os componentes de software 
usados para construir o sistema. 
 
diferente ação de projeto Artefato 
Propriedades – Definir no 
projeto 
PROPRIEDADES ESTRUTURAIS 
define os componentes de um 
sistema (por exemplo, módulos, 
objetos, filtros) e a maneira pela 
qual os componentes são 
empacotados e interagem entre 
si. 
Shaw e Garlan 
PROPRIEDADES NÃO FUNCIONAIS 
 
A descrição do projeto de 
arquitetura deve tratar a 
maneira pela qual o projeto da 
arquitetura atinge os requisitos 
de desempenho, capacidade, 
confiabilidade, segurança, 
adaptabilidade e outras 
características do sistema 
Shaw e Garlan 
FAMÍLIAS DE SISTEMAS 
Tirar proveito de padrões 
reusáveis comumente 
encontrados no projeto de 
famílias de sistemas similares. 
Em essência, o projeto deve ter a 
habilidade de reutilizar os 
componentes que fazem parte da 
arquitetura. 
Shaw e Garlan 
Conceitos de 
Projeto 
Abstração 
 Abstração é uma das maneiras 
fundamentais como nós, seres 
humanos, lidamos com a 
complexidade. 
Grady Booch 
ABSTRAÇÃO 
Foca nas características essenciais do 
objeto sob a perspectiva de quem observa 
 ABSTRAÇÃO PROCEDURAL 
 Refere-se a uma sequência de 
instruções que possuem uma 
função específica e limitada. 
 
 O nome de uma abstração 
procedural implica sua função, 
porém os detalhes específicos são 
omitidos. 
 
ABSTRAÇÃO DE DADOS 
 É um conjunto de dados com 
nome que descreve um objeto de 
dados. 
 
ARQUITETURA 
ARQUITETURA DE SOFTWARE 
 A estrutura dos componentes 
de um programa/sistema, 
seus inter-relacionamentos, 
princípios e diretrizes 
guiando o projeto e evolução 
ao longo do tempo. 
 
David Garlan e Dewayne Perry (Garlan, 1995) 
ARQUITETURA DE SOFTWARE 
 Arquitetura de software é a 
estrutura global do sistema, 
capturada através da 
organização do sistema, 
descrita em elevado nível de 
abstração, em termos dos 
elementos computacionais 
pertinentes e das interações 
entre esses elementos. 
 
 
Mendes, Antonio (2002) 
ARQUITETO DE SOFTWARE 
O arquiteto de software deve ser 
como um guia (...) que é um 
experiente e capacitado membro da 
equipe que ensina aos outros se virar 
melhor, e ainda assim está sempre lá 
para as partes mais complicadas 
 
Martin Fowler 
ARQUITETO DE SOFTWARE 
  onde o sistema a ser 
desenvolvido será 
utilizado 
 tecnologias relevantes 
 processos de 
desenvolvimento. 
Conhecimento profundo 
do domínio 
 compreensão 
profunda do 
domínio e das 
tecnologias 
pertinentes 
entendimento de 
aspectos técnicos 
para 
desenvolvimento 
de sistemas bem-
sucedidos 
Modelagem 
 
 
 
análise de 
compromissos/ 
 viabilidade 
Habilidades desejadas Tarefas Atribuídas 
Técnicas de 
elicitação, técnicas 
de modelagem e 
métodos de 
desenvolvimento 
Entendimento das 
estratégias de 
negócios da 
instituição onde 
atua 
prototipação, 
simulação, 
realização de 
experimentos 
 
análise de 
tendências 
tecnológicas 
Habilidades desejadas Tarefas Atribuídas 
 conhecimento de 
produtos, processos 
e estratégias de 
concorrentes. 
atuação como 
mentor de 
arquitetos novatos 
Habilidades desejadas Tarefas Atribuídas 
PADRÕES 
 "Padrão é parte de um 
conhecimento consolidado já 
existente que transmite a 
essência de uma solução 
comprovada para um problema 
recorrente em certo contexto, em 
meio a preocupações 
concorrentes" 
Brad Appleton 
PADRÕES 
se o padrão se aplica ou não ao 
trabalho em questão, 
se o padrão pode ou não ser 
reutilizado (e, portanto, poupando 
tempo) e 
se o padrão pode servir como um 
guia para desenvolver um padrão 
similar, mas funcional ou 
estruturalmente diferente. 
Separação por interesses (por afinidades) 
problema complexo pode ser 
tratado mais facilmente se for 
subdividido em trechos a ser 
resolvidos e/ou otimizados 
independentemente. 
estratégia dividir-para-conquistar 
Modularidade 
dividir em componentes separadamente 
especificados e endereçáveis, que são 
integrados para satisfazer os requisitos 
de um problema. 
incrementos de software possam ser definidos e 
entregues; 
as mudanças possam ser mais facilmente acomodadas; 
os testes e depuração possam ser conduzidos de forma 
mais eficaz 
manutenção no longo prazo possa ser realizada sem 
efeitos colaterais sérios. 
Independência funcional 
projetar software de modo que cada 
módulo atenda um subconjunto 
específico de requisitos e tenha uma 
interface simples quando vista de 
outras partes da estrutura do 
programa 
INDEPENDÊNCIA FUNCIONAL 
Coesão - indica a robustez 
funcional relativa de um 
módulo 
Acoplamento - indica a 
interdependência relativa 
entre os módulos.
Refatoração 
técnica de reorganização que 
simplifica o projeto (ou 
código) de um componente 
sem mudar sua função ou 
comportamento. 
PROCESSO DE 
DESENVOLVIMENTO 
NÍVEIS DE DESCRIÇÃO DE UM SISTEMA 
Decomposição da 
funcionalidade 
Arquiteturas 
(de referência) 
Arquitetura 
selecionada 
NO NÍVEL ARQUITETURAL COMPREENDE 
QUESTÕES ESTRUTURAIS 
seleção de alternativas de 
projeto; 
escalabilidade e desempenho; 
organização e estrutura geral 
de controle; 
protocolos de comunicação, 
sincronização; 
atribuição de funcionalidade a 
componentes de projeto. 
 
Mendes 
TAREFAS GENÉRICAS (PRESSMAN) 
1. Examinar o modelo do domínio de 
informação e projetar estruturas de 
dados apropriadas para objetos de dados 
e seus atributos. 
2. Usar o modelo de análise, selecionar um 
estilo de arquitetura apropriado ao 
software. 
TAREFAS GENÉRICAS (PRESSMAN) 
3. Dividir o modelo de análise em 
subsistemas de projeto e alocá-los 
na arquitetura: 
 Certificar-se de que cada subsistema 
seja funcionalmente coeso. 
 Projetar interfaces de subsistemas. 
 Alocar classes ou funções de análise 
para cada subsis-tema. 
 
 
TAREFAS GENÉRICAS (PRESSMAN) 
4. Criar um conjunto de classes ou 
componentes de projeto: 
 Traduzir a descrição de classes de análise em 
uma classe de projeto. 
 Verificar cada classe de projeto em relação aos 
critérios de projeto; considerar questões de 
herança. 
 Definir métodos e mensagens associadas a 
cada classe de projeto. 
 Avaliar e selecionar padrões de projeto para 
uma classe ou um subsistema de projeto. 
 Rever as classes de projeto e revisar quando 
necessário. 
 
TAREFAS GENÉRICAS (PRESSMAN) 
5. Projetar qualquer interface necessária para 
sistemas ou dis-positivos externos. 
 
TAREFAS GENÉRICAS (PRESSMAN) 
6. Projetar a interface do usuário: 
 Revisar os resultados da análise de tarefas. 
 Especificar a sequência de ações baseando-se nos 
cená-rios de usuário. 
 Criar um modelo comportamental da interface. 
 Definir objetos de interface, mecanismos de controle. 
 Rever o projeto de interfaces e revisar quando 
neces-sário. 
 
TAREFAS GENÉRICAS (PRESSMAN) 
7. Conduzir o projeto de componentes. 
 Especificar todos os algoritmos em um nível de 
abstração relativamente baixo. 
 Refinar a interface de cada componente. 
 Definir estruturas de dados dos componentes. 
 Revisar cada componente e corrigir todos os erros 
desco-bertos. 
 
TAREFAS GENÉRICAS (PRESSMAN) 
8. Desenvolver um modelo de implantação. 
 
Transformando o modelo de requisitos no modelo de 
projeto 
Projeto de 
Dados/ 
Classes 
•Diagramas 
de Classes 
•Pacotes de 
Análise 
•Modelos 
CRC 
•Diagramas 
de 
Colaboração 
Elementos 
baseados 
em classes 
Projeto 
Arquitetural 
•Diagramas de 
Classes 
•Pacotes de 
Análise 
•Modelos CRC 
•Diagramas de 
Colaboração 
Elementos 
baseados 
em classes 
•Diagramas de 
fluxo de dados 
•Diagramas de 
fluxo de 
controle 
•Narrativas de 
processamento 
Diagramas 
de Fluxo 
de Dados 
Projeto de 
Interfaces 
•Casos de uso - texto 
•Diagramas de Casos de 
Uso 
•Diagramas de Atividades 
•Diagramas de Raias 
Elementos 
baseados em 
cenários 
•Diagramas de estados 
•Diagramas de Sequência 
Elementos 
Comportamentais 
•Diagramas de fluxo de 
dados 
•Diagramas de fluxo de 
controle 
•Narrativas de 
processamento 
Diagramas de 
Fluxo de Dados 
•Diagramas de Classes 
•Pacotes de Análise 
•Modelos CRC 
•Diagramas de Colaboração 
Elementos 
baseados em 
classes 
•Diagramas de estados 
•Diagramas de Sequência 
Elementos 
Comportamentais 
•Diagramas de fluxo de 
dados 
•Diagramas de fluxo de 
controle 
•Narrativas de 
processamento 
Diagramas de 
Fluxo de Dados 
 
 
 Projeto 
De 
 Componentes 
DOCUMENTAÇÃO 
 O resultado do processo de projeto de 
arquitetura é um modelo de arquitetura 
que descreve como o sistema está 
organizado um conjunto de componentes de 
comunicação. 
 
Somerville 
DOCUMENTAÇÃO - VANTAGENS 
Comunicação de stakeholders. A 
arquitetura é uma apresentação de 
alto nível do sistema e pode ser usado 
como um foco de discussão por uma 
série de diferentes stakeholders 
DOCUMENTAÇÃO - VANTAGENS 
Análise de sistema. 
 As decisões de projeto de arquitetura têm 
um efeito profundo sobre a possibilidade 
de o sistema atender ou não aos requisitos 
críticos, como desempenho, confíabilidade 
e manutenibilidade. 
 
DOCUMENTAÇÃO - VANTAGENS 
Reúso em larga escala. Um modelo de 
uma arquitetura de sistema é uma 
descrição compacta e gerenciável de como 
um sistema é organizado e como os 
componentes interoperam. A arquitetura 
do sistema geralmente é a mesma para 
sistemas com requisitos semelhantes e, por 
isso, pode apoiar o reúso de software em 
grande escala. 
 
AVALIAÇÃO DO MODELO DE PROJETO 
Avaliado pela equipe de software 
 contém erros, 
 inconsistências ou omissões; 
se existem alternativas melhores; 
se o modelo pode ser implementado 
de acordo com as restrições, prazo e 
orçamento estabelecidos. 
 
REFERÊNCIAS 
 Mendes, Antonio. Arquitetura de Software: 
desenvolvimento orientado para arquitetura. Rio 
de Janeiro: Campos, 2002. 
 Capítulo 01 – páginas 1 - 8 
 Sommerville, Ian. Engenharia de Software. 9. 
Ed. São Paulo, Pearson Prentice Hall, 2011. 
 Capítulo 6 –páginas 103 - 121 
 Pressman, Roger S. Engenharia de Software: 
uma abordagem profissional. 7. ed. Porto Alegre: 
AMGH (Mc Graw Hill), 2011. 
 capítulo 8 – paginas 206 - 219 
IES300_Aula18_Documentação.pdf
FATEC/SP – DTI – IES300 
Documentação 
de 
Sistemas 
FATEC/SP – DTI – IES300 
Importância 
Pretende-se "perpetuar" os 
investimentos realizados no 
desenvolvimento dos sistemas. 
FATEC/SP – DTI – IES300 
Introdução 
representa um investimento importante para a maioria 
das empresas 
FATEC/SP – DTI – IES300 
Introdução 
adequada dos sistemas 
situações de difícil condução no caso da falta dessa pessoa 
proporciona à empresa 
expõe a empresa 
FATEC/SP – DTI – IES300 
Introdução 
minimizar o grau de dependência em relação 
a determinadas pessoas 
Encontrar alternativas para a continuidade 
dos projetos de forma menos traumática 
permite 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
 A documentação de qualquer projeto de 
desenvolvimento ou manutenção de 
sistemas deve ser aderente a uma MDMS 
que a empresa tenha adotado como padrão 
e, consequentemente, aquela que todos 
devem utilizar. 
 
 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
• A MDMS deve ser o resultado do esforço 
de todos os colaboradores da
empresa que 
reconhecem nela o meio pelo qual a 
empresa possa atender a todas as 
exigências de desenvolvimento, compra 
de sistemas/software, customização de 
sistemas, e outros projetos da área de 
Informática/Tecnologia da Informação. 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
• Além disso é importante ressaltar que a 
adoção de uma MDMS deve naturalmente 
levar a documentação dos projetos. Essa 
formalização impõe padrões que, a priori, 
todos devem procurar seguir. 
 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
• A padronização de procedimentos nos 
permitem maior controle sobre as 
atividades que são executadas durante os 
projetos, contribuindo diretamente para o 
estabelecimento de uma cultura padronizada 
de desenvolvimento e manutenção de 
sistemas 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
 A documentação adequada, aderente aos 
padrões estabelecidos e reconhecidos pela 
empresa, propicia a transferência de 
"know how" entre os colaboradores 
envolvidos. 
 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
 Sempre que citamos a problemática da 
documentação nos deparamos com um 
problema crítico que é a sua elaboração. 
Nesse contexto é recomendado que a 
MDMS deve levar à documentação, de 
preferência, apoiada por ferramentas 
automatizadas. 
 
FATEC/SP – DTI – IES300 
Metodologia de Desenvolvimento e 
Manutenção de Sistemas (MDMS) 
 A MDMS deve estabelecer padrões de 
documentação contemplando: 
desenvolvimento de sistemas, 
manutenção de sistemas, aquisição de 
pacotes, customização de pacotes, 
desenvolvimento de sistemas por 
colaboradores externos, entre outras 
formas de construção de sistemas. 
 
FATEC/SP – DTI – IES300 
Padrões 
• Utilização de práticas uniformes e técnicas 
comuns, que fornecem a base para a 
avaliação da performance em termos 
qualitativos ou quantitativos. 
FATEC/SP – DTI – IES300 
Padrões 
• Treinamento de Pessoal 
• Transferência de tarefas para pessoas com 
experiência menor 
• Avaliar os problemas de comunicação e 
diminuir a dependência de pessoas. 
• Melhorar o gerenciamento dos projetos 
FATEC/SP – DTI – IES300 
Padrões -Treinamento de Pessoal 
• Novos Elementos 
• Pode tornar-se produtivo em menor tempo, se 
seguir procedimentos já estabelecidos, em vez 
de desenvolver meios próprios. 
 
• Reciclagem de Pessoal experimentado 
FATEC/SP – DTI – IES300 
Questionamentos 
• Limitam a criatividade 
• Aumentam a carga de trabalho 
• A curto prazo será verdade, porém não o será a longo 
prazo. Temos que levar em conta as facilidades de 
conversão e manutenção. 
• Retardam o desenvolvimento do sistema. 
• Devido a existência de um conjunto formal de 
procedimentos e de documentação, que restringe a 
velocidade com que esses procedimentos podem ser 
alterados. 
FATEC/SP – DTI – IES300 
Fontes de Padronização 
• Organizações e Órgãos nacionais de 
padrões 
 
ISO - International Standards Organization 
BSI - British Standards Institution 
ANSI - United States of America National 
Standards Institute 
FATEC/SP – DTI – IES300 
Grupos de Usuários 
Constituem locais de debates, onde usuários 
comparam experiências e discutem problemas 
comuns. 
FATEC/SP – DTI – IES300 
Fabricantes 
Recomendações contidas ou implícitas em 
manuais, fornecimento de documentação aos 
usuários e também de material apresentado 
em cursos de treinamento. 
FATEC/SP – DTI – IES300 
Outras Fontes de Padronização 
• Padrões informais já em uso 
 
• Equipe do departamento 
 
FATEC/SP – DTI – IES300 
Aplicação e Execução de padrões 
• Compreender as razões 
 Toda a equipe deve compreender as razões 
para a elaboração dos padrões e dos 
métodos utilizados para a sua implantação. 
 
• Apoio da gerência 
 
Referências 
• Pressman, Roger. Engenharia de Software. 
6.ed, 2006. 
FATEC/SP – DTI – IES300 
IES300_Aula07_DIAGRAMA_MÁQUINA_ESTADOS.pdf
 demonstra o comportamento de um 
elemento por meio de um conjunto finito de 
transições de estado 
 representa a situação em que um elemento 
se encontra em determinado momento 
durante o período em que participa de um 
processo 
 A espera pela ocorrência de um evento. 
 A reação a um estímulo. 
 A execução de alguma atividade. 
 A satisfação de alguma condição. 
 
 estado que não tem subestados (não pode 
ser subdividido em estados internos) 
Consultando 
Conta 
Produto 
Suspenso Estado Estático ou de 
espera 
Executando uma Atividade 
(gerúndio) 
 representa um evento que causa uma 
mudança no estado de um objeto, gerando 
um novo estado. 
Consultando 
Conta 
Validando Conta 
Senha Informada 
 determinar o início da modelagem dos 
estados de um elemento 
 Indica o final dos estados modelados. 
 atividades que um objeto pode executar 
quando em um estado. 
Consultando Conta 
 
+ do consultar_conta() 
 Entry - identifica uma atividade que é 
executada quando o objeto assume (entra 
em) um estado. 
 Exit - identifica uma atividade que é 
executada quando o objeto sai de um 
estado. 
 Do - identifica uma atividade realizada 
durante o tempo em que o objeto se 
encontra em um estado. 
 
 não produzem modificações no estado de um 
objeto. 
 saem do estado atual do objeto, podendo 
executar alguma ação quando dessa saída, e 
retornam ao mesmo estado 
 representa uma decisão, apoiada por 
condições de guarda, em que se decidirá qual 
o próximo estado do objeto a ser gerado 
 determinar o momento em que o processo 
passou a ser executado em paralelo e em 
quantos subprocessos se dividiu. 
 determinar o momento em que dois ou 
mais subprocessos se uniram em um único 
processo 
 Contém internamente dois ou mais 
estados, chamados subestados 
 Pode apresentar somente uma região ou 
ser decomposto em duas ou mais regiões 
 não pode ser reutilizado 
 representa o registro do último subestado 
em que um objeto se encontrava, quando, 
por algum motivo, o processo foi 
interrompido. 
 estado composto que possui mais de uma 
região, onde cada região apresenta um 
conjunto de estados e os estados de cada 
região são assumidos paralelamente. 
 mecanismo de decomposição que permite a 
fatoração de comportamentos comuns e 
seu reuso 
 projetar caminhos transacionais 
complexos, podendo unir múltiplos fluxos 
em um único ou dividir um fluxo em 
diversos, podendo utilizar condições de 
guarda como auxílio. 
 Demonstram pontos de entrada e saída que 
serão somente usados em casos 
excepcionais. 
 utilizados juntamente com estados de 
submáquina ou estados compostos 
 demonstra uma exceção que causa o 
cancelamento do fluxo normal estado.
 Força o término da execução de uma 
máquina de estados (ocorrência de uma 
exceção). 
 Guedes, Gilleanes T. A. UML 2: uma 
abordagem prática. 2.ed. São Paulo: Novatec 
Editora, 2011. 
 
IES300_Aula04_Visao_Arquitetural.pdf
 
VISÃO ARQUITETURAL 
 
Arquitetura de Software 
Desafios 
•Prazo 
•Custos 
•Qualidade 
ARQUITETURA DE SOFTWARE 
 A estrutura dos componentes 
de um programa/sistema, 
seus inter-relacionamentos, 
princípios e diretrizes 
guiando o projeto e evolução 
ao longo do tempo. 
ARQUITETURA CANDIDATA 
É aquela que tem o potencial de 
apresentar comportamentos 
externos necessários e 
atributos de qualidade. 
ELEMENTO ARQUITETURAL 
É um componente claramente 
identificável e significativo. 
Stakeholder 
Pessoa, grupo ou entidade 
com interesse no sistema 
Atender 
A boa arquitetura é 
aquele que atende com 
sucesso os objetivos, 
metas e necessidades de 
seus stakeholders. 
ARQUITETURA 
• ESTRUTURA 
DO 
SISTEMA 
 
– ESTÁTICA 
 
– DINÂMICA 
• PROPRIEDADES 
DO SISTEMA 
 
– COMPORTAMENTO 
 
– ATRIBUTOS DE 
QUALIDADE 
ESTRUTURAS ESTÁTICAS 
• Definem seus elementos internos do 
projeto e sua disposição. 
• Elementos de software 
– Módulos 
– Pacotes 
– Procedimentos de armazenamento 
• Elementos de Dados 
– Classes 
– Entidades 
– tabelas 
• Elementos de hardware 
– Elemento de rede 
– Cabo 
– roteadores 
ESTRUTURAS DINÂMICAS 
• Definem seus elementos em 
tempo de execução e suas 
interações. 
– fluxos de informação entre os 
elementos 
– execução paralela ou sequencial 
de tarefas internas 
– efeito que eles tem nos dados 
 
COMPORTAMENTO DO SISTEMA 
• Define as interações funcionais 
entre o sistema e seu ambiente. 
– Fluxo de informação dentro e 
fora do sistema 
– a forma como o sistema responde 
a estímulos externos 
– API que a arquitetura tem com o 
mundo exterior 
ATRIBUTOS DE QUALIDADE 
• Propriedade visível 
externamente, propriedades 
não-funcionais de um sistema 
como o desempenho, a 
segurança ou a escalabilidade. 
 
DESCRIÇÃO DA ARQUITETURA (AD) 
É um conjunto de produtos 
que documenta uma 
arquitetura de uma forma que 
seus stakeholders possam 
entender além de demonstrar 
que a arquitetura satisfaz 
seus interesses. 
Descrição Arquitetural (ISO/IEC 
42010:2011) 
Usadas ​​pelas partes que criam, utilizam e 
gerenciam sistemas modernos para 
melhorar a comunicação e cooperação, 
permitindo-lhes trabalhar, de forma 
integrada e coerente. 
codificam as convenções 
e práticas comuns para 
arquitetar e a descrever 
as arquiteturas em 
diferentes comunidades e 
domínios de aplicação. 
ATIVOS 
DESCRIÇÃO DA ARQUITETURA (AD) 
Uma boa descrição arquitetural é 
aquele que de forma eficaz e 
consistente comunica os aspectos-
chave da arquitetura para os 
stakeholders adequados. 
Algumas questões…. 
 Quais são os principais elementos funcionais 
de sua arquitetura? 
 Como esses elementos interagem uns com 
os outros e com o mundo exterior? 
 Quais informações serão gerados, 
armazenados e apresentados? 
 Quais os elementos de hardware e software 
serão necessários para suportar esses 
elementos funcionais e de informação? 
 Quais características operacionais serão 
fornecidos? 
 O ambiente de desenvolvimento, teste, apoio 
e treinamento serão fornecidos? 
Visão 
É uma representação de 
um ou mais aspectos 
estruturais de uma 
arquitetura que ilustra 
como a arquitetura 
aborda um ou mais 
interesses de um ou mais 
stakeholders. 
Visão 
Inclua na visão apenas os 
detalhes que promovem os 
objetivos de sua AD – que é, 
os detalhes que ajudam a 
explicar a arquitetura para os 
stakeholders ou demonstrar 
que seus interesses estão 
sendo atendidos. 
Modelo de Visão – Ponto de Vista 
Arquitetural 
Produto de trabalho que 
estabelece as diretrizes para 
a construção, interpretação 
e utilização da visão 
arquitetural para enquadrar 
os interesses específicas do 
sistema. (ISO/IEC 
42010:2011) 
inclui inclui 
inclui TEM 
Pode ser documentado por 
atende 
Está de 
acordo com 
Documenta arquitetura para 
Tem um 
Refere a 
Atende as necessidades de 
Benefícios 
• Comunicação com grupos 
de stakeholders 
• Gestão da complexidade 
• Melhoria do foco do 
desenvolvedor 
P
o
n
t
o
 
d
e
 
V
i
s
t
a
 
• FUNCIONAL 
• INFORMAÇÕES 
• CONCORRÊNCIA 
• DESENVOLVIMENTO 
• IMPLANTAÇÃO 
• OPERACIONAL 
FUNCIONAL 
• Descreve os elementos 
funcionais do sistema, as 
suas responsabilidades, 
interfaces e interações 
primárias 
INFORMAÇÕES 
• Descreve a forma que a 
arquitetura armazena, 
manipula, controla e 
distribui informação 
CONCORRÊNCIA 
• Descreve a estrutura de 
concorrência do sistema e 
mapeia elementos funcionais às 
unidades de concorrência 
(simultaneidade) para 
identificar claramente as partes 
do sistema que pode executar 
simultaneamente e como isso é 
coordenado e controlado. 
DESENVOLVIMENTO 
• Descreve a arquitetura que 
suporta o processo de 
desenvolvimento de software. 
Comunicam os aspectos da 
arquitetura de interesse para 
aqueles stakeholders 
envolvidos na construção, 
testes, manutenção e melhoria 
do sistema. 
IMPLANTAÇÃO 
• Descreve o ambiente no qual o sistema 
será implantado, incluindo as 
dependências que o sistema tem em seu 
ambiente de execução. 
• Captura o ambiente de hardware que o 
sistema precisa (principalmente os nós de 
processamento, interconexões de rede, e 
facilidades de armazenamento em disco 
necessárias) 
• Captura os Requisitos técnicos de 
ambiente para cada elemento 
• Mapeia os elementos de software para o 
ambiente em tempo de execução. 
OPERACIONAL 
• Descreve como o sistema será 
operado, administrado, e 
suportado quando ele está 
sendo executado em seu 
ambiente de produção 
Visões segundo Kruchten (1995) 
• visão lógica 
• visão de processo 
• visão do desenvolvimento 
• visão física 
VISÃO LÓGICA 
• mostra as abstrações 
fundamentais do sistema como 
objetos ou classes de objetos. 
Nessa visão, deveria ser possível 
relacionar os requisitos de 
sistema com as entidades 
VISÃO DE PROCESSOS 
• mostra como, em tempo de 
execução, o sistema é composto 
de processos interativos 
• útil para analisar as 
características não funcionais 
do sistema, como desempenho e 
disponibilidade. 
 
VISÃO DO DESENVOLVIMENTO 
• mostra como o software é 
decomposto para o 
desenvolvimento ( apresenta a 
distribuição do software em 
componentes que são