Material - Módulo 2 - Arquiteto (A) de Software

Desenvolvimento de
Requisitos Arquiteturais
Capítulo 1. Introdução à Engenharia de Requisitos
Prof. Augusto Farnese

Desenvolvimento de
AULA 1.1. REQUISITOS ARQUITETURAIS E FUNCIONAIS
PROF. AUGUSTO FARNESE

Nesta aula
 Os requisitos arquiteturais nas atividades de

requisitos tradicionais.
 Por que se preocupar com requisitos arquiteturais?

Requisitos funcionais e
não-funcionais
1 Requisitos
funcionais
2 Requisitos
não-funcionais
Requisitos
Funcionais
Muita gente solicitando

e dando opinião
Mais definir e mostrar os

resultados esperados
Observável por clientes e

quem usa o sistema
Requisitos
Não-funcionais
Muitas vezes negligenciados

no planejamento
Resultados são
menos tangíveis
Geralmente deixado a cargo

apenas do time técnico
Requisitos
Não-funcionais
Desempenho Usabilidade
Confiabilidade Segurança
Disponibilidade Manutenibilidade
Sina dos Requisitos
Não-Funcionais
Não haver uma

negociação adequada
Não serem contemplados no

backlog do produto
Serem considerados implícitos

nos requisitos funcionais
Conclusão
 Requisitos não-funcionais são menos
tangíveis do que os requisitos funcionais.
 Geralmente não é feita uma boa gestão

dos requisitos não-funcionais e deixados
a cargo da equipe técnica.
Próxima aula
01. 03.
Produto BDUF
Mínimo Viável
02. 04.
Arquitetura
Mínima Viável
Desenvolvimento de
AULA 1.2. ARQUITETURA MÍNIMA VIÁVEL

Nesta aula
01. 03.
Produto BDUF
Mínimo Viável
02. 04.
Arquitetura
Mínima Viável
Cone da
Incerteza
BDUF: Big Design Up-Front
Tomar decisões no
início do projeto
Mais presente em
abordagens tradicionais
Princípio do
Manifesto Ágil
As melhores arquiteturas,
requisitos e designs
emergem de times
auto-organizáveis
MVP
Produto Mínimo Viável
1 2
Qual o menor Como validar as
investimento que cria hipóteses de mercado
o máximo de valor? ou produto da maneira
mais rápida?
MVP
Ciclo de
Aprendizagem
Ciclo de
Aprendizagem
Arquitetura Mínima Viável
‘‘
‘‘
Tentar construir o sistema perfeito
raramente é a abordagem correta
Conclusão
 É melhor postergar as decisões quando a
incerteza é grande.
 A cada ciclo fazer o mínimo necessário.

Próxima aula
01. 03.
Processo Ritos de
Cascata vs. Iterativo agilidade e
arquitetura
02. 04.
Spikes
Desenvolvimento de
AULA 1.3. ARQUITETURA E AGILIDADE

Nesta aula
 Processo iterativo e incremental.
 Spikes.
 Liderança Técnica em Times Ágeis.
 Conceito de Preparado e Pronto.
 Revisão e Retrospectiva de Sprints.

Modelo de Processo
em Cascata
Requisitos
Desenho
Implementação
Integração
Testes
Implantação
Entrega
Desenho e Construção a
Cada Sprint
Início do Fim do
Projeto ... Projeto
ITERAÇÃO 1 ITERAÇÃO 2 ITERAÇÃO 3 ITERAÇÃO 4
Entrega
Spikes
 Riscos técnicos.
 Tarefas com ”timebox”.
 Responsável deve atacar o problema.
História
nebulosa
Liderança Técnica
em Times Ágeis
 Alinhar o entendimento com a equipe.
 Contato frequente com o

Dono do Produto.
 Identificar os riscos técnicos:

 SPIKES.
Conceitos de
Preparado e Pronto
Preparado para
entrar na sprint
Pronto para
entrega
Revisão e
Retrospectiva da Sprint
 Discutir:
 Como melhorar processo de construção;
 Como melhorar arquitetura;
 Quais os riscos à frente.

Conclusão
 O produto é construído de maneira
incremental.
 Deve-se ter grande alinhamento

entre o time.
 Usar os ritos ágeis para melhoria

contínua da arquitetura.
Próxima aula
01. 03.
Manifesto Ágil
02. 04.
Os 12 princípios
por trás do
Manifesto Ágil
Desenvolvimento de
AULA 1.4. MANIFESTO ÁGIL

Nesta aula
 Manifesto Ágil.
 Os 12 princípios por trás do manifesto.

Manifesto Ágil
mais que
Indivíduos e Interações Processos e Ferramentas
Software que funciona Documentação Abrangente
Colaboração com o Cliente Negociação de Contratos
Resposta a Mudanças Seguir um Plano

‘‘
Nossa maior prioridade é
satisfazer o cliente, através da
entrega adiantada e contínua
de software de valor.
‘‘
Aceitar mudanças de
requisitos, mesmo no fim do
desenvolvimento. Processos
ágeis se adequam a
mudanças, para que o cliente
possa tirar vantagens
competitivas.
‘‘
Entregar software funcionando
com frequência, na escala de
semanas até meses, com
preferência aos períodos
mais curtos.
‘‘
Pessoas relacionadas à
negócios e desenvolvedores
devem trabalhar em conjunto
e diariamente, durante todo o
curso do projeto.
‘‘
Construir projetos ao redor de
indivíduos motivados. Dando
a eles o ambiente e suporte
necessário, e confiar que
farão seu trabalho.
‘‘
O método mais eficiente e
eficaz de transmitir
informações para, e por
dentro de um time de
desenvolvimento, é através de
uma conversa cara a cara.
‘‘
Software funcional é a
medida primária de progresso.
‘‘
Processos ágeis promovem um
ambiente sustentável. Os
patrocinadores,
desenvolvedores e usuários,
devem ser capazes de manter
indefinidamente, passos
constantes.
‘‘
Contínua atenção à
excelência técnica e bom
design, aumenta a agilidade.
‘‘
Simplicidade: a arte de
maximizar a quantidade de
trabalho que não precisou ser
feito.
‘‘
As melhores arquiteturas,
requisitos e designs emergem
de times auto-organizáveis.
‘‘
Em intervalos regulares, o time
reflete em como ficar mais
efetivo, então, se ajustam e
otimizam seu comportamento
de acordo.
Conclusão
 Agilidade está nas atitudes do dia a dia.
 As definições arquiteturais também

precisam ser ágeis.
Próxima aula
01. 03.
Arquitetura
Incremental
02. 04.
Design
Evolutivo
Desenvolvimento de
AULA 1.5. ARQUITETURA INCREMENTAL E DESIGN EVOLUTIVO

Nesta aula
 Estratégias intencionais da arquitetura.
 Reações orgânicas das decisões de design.

Arquitetura emerge de
desenvolvedores criando o
sistema para ver o que
funciona
Arquitetura Intencional
e Design Emergente
Arquitetura
Intencional
Define um conjunto de estratégias
e iniciativas intencionais
Melhoram o design da solução,

desempenho e usabilidade
Provê caminho para sincronização

da implementação e design entre
vários times
Design Emergente
Provê base técnica para uma

abordagem evolutiva e incremental
Ajuda desenvolvedores e arquitetos

a responder imediatamente às
necessidades dos usuários
Permite que a arquitetura evolua à

medida que o sistema é construído
Arquitetura Evolui
com os Times
NÍVEL DE ABSTRAÇÃO
Alto
Baixo
Evolução Incremental
da Arquitetura
ARQUITETURA MÍNIMA VIÁVEL
DESENHO EMERGENTE
Conclusão
 Deve mesclar entre as restrições
intencionais da arquitetura e as
decisões orgânicas do time.
 Arquitetura evolui incremental e

iterativamente.
Próxima aula
01. 03.
Sistemas
Legados
02. 04.
Estratégias de
Evolução
Desenvolvimento de
AULA 1.6. SISTEMAS LEGADOS

Nesta aula
 Sistemas legados.
 Convivência entre antigo e novo.
 Estratégias para lidar com legado.

Sistemas Legados
1 Sistemas em tecnologias
“ultrapassadas” ainda em uso
2 Manutenção desafiadora
3 Geralmente não é fácil

achar profissionais
Velho e Novo
Velho e Novo
Belo Horizonte:
Uma cidade planejada
Definir uma
Estratégia
 Evoluir o velho.
 Fazer tudo novo.
 Evoluir o velho e fazer o novo.

Conclusão
 Conviver com sistemas legados
geralmente não é uma opção.
 É importante definir a estratégia de

evolução e retirada dos sistemas
legados.
Próxima aula
01. 03.
Responsabilidades de Times.
02. 04.
Desenvolvimento de
AULA 1.7. RESPONSABILIDADES DE TIMES

Nesta aula
 Responsabilidades de Times.
Times em empresas
com muitas pessoas
Dados e Design
Arquitetura
Analytics
Produto E
Banco de
Dados
Produto D
Produto A Produto B
Produto C
Infra
Times em empresas
com poucas pessoas
Conclusão
Responsabilidades de Times.
Próxima aula
01. 03.
Capítulo 2.
02. 04.
Desenvolvimento de
Capítulo 2. Elicitação De Requisitos Arquiteturais

Desenvolvimento de
AULA 2.1. INTRODUÇÃO À ENGENHARIA DE REQUISITOS

Atividades da ER
ELICITAÇÃO
ANÁLISE
ESPECIFICAÇÃO
VALIDAÇÃO
Elicitação de Requisitos
Conhecer o
domínio do
problema
Definir o
escopo do
produto
Mapear as
fontes de
requisitos
Análise de Requisitos
Modelagem
conceitual
Análise de
Custo /
Benefício
Identificar
conflitos
Classificar
requisitos
Especificação de requisitos
Validação de requisitos
Conclusão
 Ciclo de vida dos requisitos deve ser
levado para requisitos funcionais e
também não funcionais.
Próxima aula
01. 03.
Gestão de Entender o
Produtos Problema
02. 04.
VUCA
Desenvolvimento de
AULA 2.2. GESTÃO DE PRODUTOS E MUNDO VUCA

Nesta aula
 O que é gestão de produtos.
 Mundo VUCA.
 Entender o problema antes de pensar a solução.

Gestão de Produtos
Design
Tecnologia Negócios
Ciclo de
Gestão de Produtos
Definir próximos
passos
Definir os Acompanhar
objetivos construção
Validar o que
foi feito
Mundo VUCA
Entender o Problema
Conclusão
 A arquitetura não pode pensar apenas
na parte técnica.
 A arquitetura deve pensar o Problema.
 Devemos abraçar o mundo VUCA e

não tentar evitá-lo.
Próxima aula
01. 03.
Tipos de Vantagens de
Conhecimento processos
criativos
02. 04.
Conhecimento
Tácito
Desenvolvimento de
AULA 2.3. TIPOS DE CONHECIMENTO

Nesta aula
 Tipos de conhecimento.
 Formas de abordar conhecimento “inacessível”.

Desafio: Levantar os
conhecimentos necessários
Requisitos faltantes ou
errados podem sabotar o
sucesso do projeto
Expertise no domínio do problema

pode levar a omissão de
conhecimento tácito
Conhecimento
Tácito
‘‘
Aquele que o indivíduo
adquiriu ao longo da vida,
pela experiência
Desafios com
conhecimento tácito
1 Identificar
2 Saber o que é relevante e

deve ser articulado
3
Articular o conhecimento no
contexto certo para que seja
conhecido por stakeholders
Tipos de
Conhecimento
Conhecimento
Não sabe Sabe

que sabe que sabe
Não sabe Sabe

que não sabe que não sabe
Consciência
Em direção ao
desconhecido desconhecido
Conclusão
 Descoberta de requisitos não é um
processo “em linha reta”.
 Cuidado com conhecimento tácito.

Próxima aula
01. 03.
Relatório do Stakeholders
Chaos
02. 04.
Sucesso do Desafios com
Projeto requisitos
arquiteturais
Desenvolvimento de
AULA 2.4. DESAFIOS DA ELICITAÇÃO DE REQUISITOS ARQUITETURAIS

Nesta aula
 Relatório do CHAOS.
 Critérios de sucesso do projeto.
 Desafios com requisitos arquiteturais.
 Identificação de Stakeholders.
Funcionalidades que
ninguém usa
O Sucesso do Projeto
ESCOPO
O Sucesso
do Gerenciamento do Projeto
ESCOPO
O Sucesso do Projeto
SATISFAÇÃO
Em uma má gestão
de requisitos:
‘‘
‘‘
Só mais uma coisa, isso
não deve ser difícil
‘‘
‘‘
Isso não está claro, então
vamos assumir que...
‘‘
‘‘
Aposto que eles também
gostariam disso aqui...
Identificação de
“stakeholders”
Têm posição relevante na empresa;
Tomam as decisões no sistema novo;
Dominam o problema;
São expostas aos problemas perceptíveis;
Podem influenciar a aceitação do sistema;
Tem seus objetivos pessoais relacionados.

Conclusão
 Temos que considerar a satisfação

como elemento de sucesso.
 Cada perfil encara requisitos de

sua maneira.
 Pode ser difícil chegar aos

requisitos “ideais”.
Próxima aula
01. 03.
Processo Ritos de
Cascata vs. Iterativo agilidade e
arquitetura
02. 04.
Spikes
Desenvolvimento de
Capítulo 3. Análise de Requisitos Arquiteturais

Desenvolvimento de
AULA 3.1. PRIORIZAÇÃO DE REQUISITOS

Nesta aula
 Prioridade de requisitos.
 Kano Model.
 Cost of Delay (custo do atraso).

Priorizar
1 Garantir que os próximos

requisitos geram mais valor
2 Evitar desperdício
Kano Model
Cost of Delay
1 Qual o valor do que estamos

fazendo agora?
2 Qual a urgência do
que estamos fazendo?
Cost of Delay
CD3
CD3
Sair do
Cost of Scream
Conclusão
 Kano Model é mais voltado para

satisfação.
 Cost of Delay é voltado para

retorno financeiro.
Próxima aula
01. 03.
Histórias de
Usuários
02. 04.
Comece pelo
porquê
Desenvolvimento de
AULA 3.2. HISTÓRIAS DE USUÁRIOS

Nesta aula
 Histórias de Usuários.
 Círculo de Ouro.
História de Usuário
Descrição do requisito do ponto de vista de
quem usa o sistema.
Segue o modelo:
Eu <usuário>
preciso <necessidade>
porque <justificativa>
Dono do produto é responsável por registrar as

histórias.
Comunicação
 Dono do produto deve manter a comunicação
com o time e as partes interessadas.
 Histórias estimulam a conversa.
 Fotografia da funcionalidade.
Conversa vale mais
do que o escrito
Vantagens
Enfatizam conversa
Encorajam pedir
com
detalhes
desenvolvedores
Funcionam bem com

Tem tamanho certo
desenvolvimento
para o planejamento
iterativo
Círculo de Ouro
Histórias de Usuário
 Análise ou
 Especificação?
Conclusão
 Histórias de usuários enfatizam a
comunicação.
 Deve ser usados para se pensar na

motivação para um requisito.
Próxima aula
01. 03.
Débito Técnico
02. 04.
Desenvolvimento de
AULA 3.3. DÉBITO TÉCNICO

Nesta aula
 Débito Técnico.
Débito Técnico é um
Empréstimo
Débito Técnico
Não é
 Bug.
 Gambiarra.
 Entrega a qualquer custo.
 Desculpa para não fazer boa

programação.
Débito Técnico
É
 Construir software eficaz, mas não
eficiente.
 Possibilidade de refatoração e
melhoria.
 Abrir mão de melhores práticas para

garantir entrega.
 Lembrar de voltar para melhorar.

Um mal necessário
Arquitetura Mínima Viável
‘‘
‘‘
Tentar construir o sistema perfeito
raramente é a abordagem correta
Conclusão
 Planejar débito técnico.
 Alinhar com times quando algo surgir.
 Colocar débito técnico no Backlog.

Próxima aula
01. 03.
FURPS+
02. 04.
Desenvolvimento de
AULA 3.4. FURPS+

Nesta aula
 FURPS+
FURPS
FURPS+
 Restrições de Design:
 Padrões de Design;
 Processo de Desenvolvimento de Software;
 Uso de Ferramentas de Desenvolvimento;
 Biblioteca de Classes;
 ...
FURPS+
 Requisitos de Implementação:
 Limites de Recursos;
 Sistemas operacionais;
 ...
 Requisitos de Interface.
 Requisitos Físicos.
Requisitos
 O produto deve ser localizado (suportar múltiplos

idiomas);
 Requisito de Suportabilidade.
 A base de dados deve ser MongoDB;

 Requisito de Design.
 O sistema deve estar on-line 7/24;

 Requisito de confiabilidade.
Importância de Classificar
 Agrupar requisitos relacionados, que podem parecer

independentes.
 Ajuda a fazer as perguntas certas para stakeholders.

Conclusão
 Classificar os requisitos para garantir
uma visão geral da necessidade.
Próxima aula
01. 03.
Acessibilidade
02. 04.
Desenvolvimento de
AULA 3.5. ACESSIBILIDADE

Nesta aula
 Por que investir em acessibilidade?
 Tipos de deficiências.
Acessibilidade não é melhor só
para pessoas com deficiências
Conteúdo
Mais
melhor para
acessibilidade
público em geral
Por que investir em
acessibilidade?
Quanto menos
usuários, menos
clientes!
Por que investir em
acessibilidade?
 Em sistemas governamentais sem

acessibilidade, alguns usuários
são privados de funções
básicas da cidadania
Exemplos de
Deficiências
Cegueira
Daltonismo
Problemas motores
Dislexia
Deficiência de visão
Tipos de Problemas
Permanentes Situacionais
Temporários
Conclusão
 Acessibilidade torna o sistema melhor
para o público em geral.
 Deve ser pensada estrategicamente.

Próxima aula
01. 03.
Desempenho
02. 04.
Desenvolvimento de
AULA 3.6. DESEMPENHO

Nesta aula
 Desempenho e objetivos de negócio.
 Lentidão e reação dos usuários.

Desempenho tem a ver com os
objetivos de negócio
Desempenho melhora a
capacidade do usuário realizar
suas atividades
Sem interrupção Sem perda de

cognitiva foco da tarefa
Ferramenta não é
um gargalo no
processo
Lentidão e reação
dos usuários
100 - 300 300 - 1000

0 - 16 ms 0 - 100 ms > 1000 ms
ms ms
Tempo ideal para Tempo ideal de Usuário nota um leve Usuário percebe o Usuário perde o foco
cada quadro de uma resposta para uma atraso na resposta da atraso como uma na tarefa que está
animação acontecer. ação do usuário. aplicação. troca de tarefa. realizado. Mais do
Mais do que isso o Natural para tarefas que 10.000 ms o
usuário pode finalizadas, mas um usuário fica frustrado
perceber a falta de atraso para e pode abandonar a
fluidez operações dentro de tarefa.
uma mesma tarefa.
Conclusão
 Analisar a necessidade de desempenho
de acordo com os objetivos do negócio.
 Mensurar o impacto nos usuários.

Próxima aula
01. 03.
Usabilidade
02. 04.
Desenvolvimento de
AULA 3.7. USABILIDADE

Nesta aula
 Usabilidade.
 Atributos de Usabilidade.
O que é qualidade?
Usabilidade Acessibilidade Desempenho
Suporte a
SEO Responsividade diversos
navegadores
Usabilidade
‘‘
Medida pela qual um produto pode
ser usado por usuários
específicos para alcançar
‘‘
objetivos específicos com
efetividade, eficiência e
satisfação.
(ISO 9241-11)
Atributos de Usabilidade
Aprendizado • Interface ajuda usuário a aprender.
Eficiência • Usuário experiente realiza tarefas rapidamente.
• Usuário se lembra como usar o sistema,

Memorização
mesmo depois de muito tempo sem usar.
Robustez • Sistema ajuda o usuário a se recuperar do erro.
Satisfação • O usuário precisa ficar satisfeito ao utilizá-lo.

Conclusão
 É importante definir as necessidades em
termos de usabilidade.
 Pensar os impactos da usabilidade na

arquitetura.
Desenvolvimento de
Capítulo 4. Especificação e Validação de Requisitos Arquiteturais

Desenvolvimento de
AULA 4.1. REQUISITOS INVEST

Nesta aula
❑ Requisitos INVEST.
INVEST
• Independente
• Negociável
• Valor
• Estimável
• Small (pequena)
• Testável
Conclusão
✓ Ciclo de vida dos requisitos deve ser
levado para requisitos funcionais e
também não funcionais.
Próxima aula
01. 03.
Casos de Uso
02. 04.
Desenvolvimento de
AULA 4.2. CASOS DE USO

Nesta aula
❑ Casos de Uso.
❑ Estrutura.
❑ Vantagens.
Casos de Uso
▪ Representação de um requisito funcional
▪ Narrativas em texto
▪ Uma unidade de trabalho funcional
▪ Amplamente utilizado em desenvolvimento de

software
Diagrama de
Casos de Uso
Estrutura
▪ Nome
▪ Sumário
▪ Pré-condições
▪ Gatilhos
▪ Linha de Eventos
▪ Percursos Alternativos
▪ Pós condições
▪ Regras de negócio
Vantagens
▪ Fáceis de entender
▪ Ponte entre quem desenvolve, quem

usa e clientes
▪ Visualizar os caminhos alternativos
▪ Estão ligados à interação com o sistema
▪ Diagrama padronizado
Desvantagens
▪ Não são bons para requisitos não-

funcionais
▪ Uso de template não garante clareza
▪ Depende de quem escreve
▪ Não é completo
▪ Necessário contexto para entende-los
▪ Podem tomar a equipe muito centrada em

documentação
Casos de Uso ou
Histórias de Usuário
▪ Foco no Problema vs. Foco na Solução
▪ Estrutura do Time
▪ Tipo de projeto
▪ Não existe “Bala de prata”

Conclusão
✓ Casos de uso são úteis para
representar requisitos funcionais
✓ Devem ser bem preenchidos para

serem claros para a equipe de
desenvolvimento
✓ Têm foco na solução. As histórias de

usuários focam mais no problema.
Próxima aula
01. 03.
Modelo 4+1
02. 04.
Desenvolvimento de
AULA 4.3. MODELO 4+1 DE VISÃO ARQUITETURAL

Nesta aula
❑ Por que modelar?
❑ Modelo 4+1
❑ Importância de diferentes visões

Modelagem
• Modelo é uma abstração da
realidade
• Captura os elementos importantes

para discussões e tomadas de
decisão
Por que modelar?
• Estruturar soluções
• Experimentar
• Simplificar questões complexas (abstrair)
• Mapear riscos
• Evitar erros
Sistemas têm vários aspectos
• Uma única visão não captura todos os aspectos de um
sistema
Modelo 4+1
Visão de
implementação
Visão Lógica
Visão de Caso
de Uso
Visão de
Visão de Processo
Implantação
Utilidades
• Tratar separadamente requisitos funcionais e não-
funcionais
• Ajuda a lidar com o desenho e implementação da

estrutura alto-nível do software (arquitetura)
Nem sempre precisamos de
todas as visões
Sistema pequeno Ignore a visão de implementação
Processador único Ignore a visão de implantação
Processo único Ignore a visão de processos
▪ Alguns sistemas podem precisar de visões adicionais:

❖Visão de Dados
❖Visão de Segurança
❖Outros aspectos
Conclusão
✓ Várias visões ajudam a ter uma noção
global do sistema
Próxima aula
01. 03.
As visões do
Modelo 4+1
02. 04.
Desenvolvimento de
AULA 4.4. AS VISÕES DO MODELO 4+1

Nesta aula
❑ Cada uma das visões do Modelo 4+1

Modelo 4+1
Visão de
implementação
Visão Lógica
Visão de Caso
de Uso
Visão de
Visão de Processo
Implantação
Visão Lógica
• Demonstra as partes que integram o sistema e suas interações.
• Representa um agrupamento de abstrações e enfatiza classes e objetos.
• Descreve a modelagem de objetos.

• Diagramas de classe (Class diagrams);
• Diagramas de estado (State diagrams);
• Diagramas de objeto (Object diagrams);
• Diagramas de sequência (Sequence diagrams);
• Diagramas de comunicação (Communication diagrams).
Visão de Processo
• A visão de processo descreve os processos do sistema, demonstrando
toda comunicação entre seus processos.
• Explora o que deve acontecer dentro do sistema.
• Particularmente importante quando você terá processos ou threads sendo

executados simultaneamente.
• Diagrama de atividade (activity diagram).
Visão Física
• Demonstra o ambiente de execução do sistema.
• Se mapeia os artefatos de software ao hardware que hospedará estes

artefatos.
• Diagrama de implementação (deployment diagram).
Visão de Desenvolvimento
• Descreve os módulos do sistema, ou seus componentes, incluindo
pacotes, sub-sistemas e bibliotecas de classes.
• Muito útil na gestão de camadas do sistema.

• Diagramas de componente (Component diagrams);
• Diagramas de pacote (Package diagrams).
Visão de Caso de Uso
Demonstra as funcionalidades do sistema.
Captura os objetivos do usuário e os cenários de utilização do sistema.
Ajuda a definir e explicar as estruturas e funcionalidades que compõem as

outras quatro visões.
• Diagrama de caso de uso (use case diagram)
• Casos de uso e requisitos do sistema.

Próxima aula
01. 03.
UML
02. 04.
Desenvolvimento de
AULA 4.5. INTRODUÇÃO A UML

Nesta aula
❑ O que é UML
UML
▪ UML: Linguagem de Modelagem Unificada
▪ Notação gráfica
▪ Não é linguagem de programação
▪ Modelar sistemas orientados a objetos
▪ Define diagramas padronizados
▪ É complexa (vários diagramas)

UML
▪ Combina conceitos de várias notações
▪ Abrangente
▪ Modelagem de negócios, Requisitos, Análise,
Desenho, Implementação, Testes, Implantação
▪ Independente de linguagem, plataforma ou

processo
▪ Suportada por várias ferramentas

Diagramas UML
Conclusão
✓ UML é uma padronização útil para
modelagem de software
✓ Vários diagramas
✓ (Vamos ver alguns nas próximas aulas)

Próxima aula
01. 03.
Diagrama de
Classes
02. 04.
Tipos de
Associações entre
Classes
Desenvolvimento de
AULA 4.6. DIAGRAMA DE CLASSES

Nesta aula
❑ Diagrama de Classes
❑ Tipos de Associações entre classes

Diagrama de Classes
• Ilustra a estrutura de um sistema descrevendo
CLASSES, seus atributos, métodos e
relacionamentos entre elas
• Lembrando o que é uma classe:

• Um template para criar objetos, assim como
representar o estado inicial do objeto, atributos
e métodos
Diagrama de Classes
• Serve de apoio para a maioria dos outros
diagramas
• O mais importante e mais utilizado diagrama da

UML
Diagrama de Classes
Classe e Objeto
Blocos da
Representação da Classe
Perspectiva conceitual
Perspectiva conceitual
Perspectiva de Especificação
Perspectiva de Especificação
Perspectiva de Implementação
Perspectiva de Implementação
Relacionamentos
Associação
Associação
❑ Descreve um vínculo entre duas classes
❑ Determina que as instâncias de uma classe

estão de alguma forma ligadas às
instâncias da outra classe
Multiplicidade
Agregação
• Tipo especial de associação
• Demonstra que as informações de um objeto precisam

ser complementadas por um objeto de outra classe
Agregação
• Representada por um losango vazado na extremidade
da classe que contem os objetos-todo
Composição
• Vínculo mais forte entre objetos-todo e objetos-parte
• A “parte” tem que pertencer ao “todo”

• O todo não faz sentido sem as partes
• Ou as partes não fazem sentido sem o todo
Composição
• Representada por um losango preenchido na
extremidade da classe que contem os objetos-todo
Especialização / Herança
• Identifica as super-classes e sub-classes
• Geral e especializadas
• Semântica “é um”
• Tudo que as classes geral podem fazer as classes
específicas também pode
• Todos os atributos e métodos são herdados

Especialização / Generalização
Especialização / Generalização
Conclusão
✓ Diagrama de classes é a base para os
outros
✓ Mostrar a estrutura e os
relacionamentos entre as classes
Próxima aula
01. 03.
Diagrama de
Sequência
02. 04.
Desenvolvimento de
AULA 4.6. DIAGRAMA DE SEQUÊNCIA

Nesta aula
❑ Diagrama de Sequência
Os principais
diagramas UML
▪ Cinco diagramas UML representam a
essência da maioria dos sistemas
▪ Diagrama de Casos de Uso
▪ Diagrama de Classes
▪ Diagrama de Sequência
▪ Diagrama de Atividades
▪ Diagrama de Estados
É um diagrama de
Comportamento
Diagramas UML
Comportamento Estrutura
Máquina de
Atividade Sequência Comunicação Casos de Uso Classe Base de Dados Componente Implementação
Estados
Diagrama de Sequência
❑ Representa como objetos interagem para

executar um serviço
❑ Captura o comportamento de uma

funcionalidade
➢ Ex: Um caso de uso específico
❑ A interação é representada através da

troca de mensagens
❑ Leva em consideração a ordem temporal em

que as mensagens são trocadas
❑ São identificados no diagrama

➢ Evento gerador da funcionalidade modelada
➢ Objetos envolvidos na ação

O que representam?
❑ Mostram a sequência em que eventos ocorrem

num determinado processo
➢ Quais condições devem ser satisfeitas
➢ Quais métodos devem ser disparados
➢ Em que ordem os métodos são disparados
❑ Atenção: Não representam atributos

Atores
❑ Os mesmos descritos no Diagrama de Casos

de Uso
❑ Entidades externas que

➢ Interagem com o sistema
➢ Solicitam serviços
Objetos
❑ Indicam as instâncias de uma classe envolvida

no processo
➢ Mostradas no Diagrama de Classe
❑ Representados por retângulos

➢ Nome do Objeto (inicial minúsculo)
➢ Nome da Classe (inicial maiúscula)
➢ Separação por dois pontos (:)

Linha de Vida
❑ Linha vertical tracejada abaixo do objeto
❑ Representa o tempo em que um objeto existe

durante o processo
Ativação do Objeto
❑ Objeto é ativado quando recebe um estímulo

➢ Ex: Recebe uma mensagem
❑ Um retângulo mais fino indica o período em que o objeto

está participando ativamente do processo
Ativação do Objeto
❑ Objeto pode ser ativado em vários momentos

Conclusão
✓ Diagrama de sequência é do tipo
comportamental e mostra interação
entre classes.
Próxima aula
01. 03.
Troca de
Mensagens no
Diagrama de
Sequência
02. 04.
Desenvolvimento de
AULA 4.7. TROCA DE MENSAGENS EM DIAGRAMAS DE SEQUÊNCIA

Tipos de Mensagem
❑ Ator para Ator
❑ Ator para Objeto
❑ Objeto para Objeto
❑ Objeto para Ator

Ator para Ator
❑ Indica conversa entre atores
❑ Podem não fazer parte do sistema

➢ Mas facilita a compreensão do processo
❑ Pouco comum de se modelar

Ator para Ator
Ator para Objeto
❑ Indica uma solicitação de serviço feito pelo ator

ao sistema
❑ Ator produz um evento que força o disparo de

um método
❑ Tipo comum quando se modela casos de Uso

Ator para Objeto
Objeto para Objeto
❑ Indica que um objeto transmite mensagem

para outro objeto
➢ Ex: Solicitar execução de um método
❑ Tipo mais comum de troca de mensagem

Objeto para Objeto
Objeto para Ator
❑ Indica a resposta de uma solicitação de serviço

feita por um ator
➢ Geralmente quando o objeto envia uma
mensagem de retorno
❑ Mensagens de retorno são representadas por

linhas tracejadas
➢ Pode ter legenda indicando o retorno
Objeto para Ator
Instanciação de Objeto
❑ A seta atinge o retângulo que representa o

Objeto
➢ O Objeto passa a existir a partir daquele momento
❑ A mensagem representa a chamada do método

construtor
Instanciação de Objeto
Conclusão
✓ Diagrama de Sequência mostra a
interação entre elementos do sistema
Próxima aula
01. 03.
Diagrama de
Casos de Uso
02. 04.
Desenvolvimento de
AULA 4.8. DIAGRAMAS DE CASOS DE USO

Nesta aula
❑ Diagrama de Casos de Uso

Diagrama de Casos de Uso
❑ Linguagem simples
➢ Acessível a clientes
❑ Objetivo: Compreensão do comportamento externo

do sistema por partes interessadas
❑ Apresenta o sistema de perspectivas dos usuários

❑ O diagrama mais abstrato da UML

➢ Mais flexível e informal
❑ Geralmente usado no início da modelagem do

sistema
➢ Especificação de requisitos
❑ Visão externa geral das funções e serviços

➢ Define o que o sistema faz
➢ Não se preocupa em como o sistema faz
❑ Indica as funcionalidades que o sistema precisa oferecer

Componentes
❑ Atores
❑ Casos de Uso
❑ Relacionamentos
Atores
❑ Papeis desempenhados por usuários

➢ Cliente, Professor, Aluno, Supervisor, Etc.
❑ Atores podem ser

➢ Pessoas interagindo com sistema
➢ Hardware disparando interação
➢ Outro software se comunicando com o sistema
❑ Não faz parte do sistema, mas interage com ele em

algum momento
Atores (representação)
Casos de Uso
❑ Definem interações entre sistema e atores
❑ Define serviços, tarefas ou funções do sistema
❑ Nomes indicam ação (verbos)
❑ Representado por elipses

➢ Descrição nas elipses costuma ser curta e direta
Casos de Uso (representação)
Relacionamentos
❑ Principais tipos
➢ Associação
➢ Inclusão
➢ Extensão
➢ Generalização
❑ Representam interações entre

➢ Atores e casos de uso
➢ Dois ou mais Casos de Uso
➢ Dois ou mais atores

Relacionamentos
Conclusão
✓ Casos de uso representam as
funcionalidades do sistema, atores e
seus relacionamentos.
✓ Casos de Uso são descritos como

vimos na 4.2

Material - Módulo 2 - Arquiteto (A) de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Material - Módulo 2 - Arquiteto (A) de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento de

Prof. Augusto Farnese

PROF. AUGUSTO FARNESE

 Os requisitos arquiteturais nas atividades de

 Por que se preocupar com requisitos arquiteturais?

Muita gente solicitando

Mais definir e mostrar os

Observável por clientes e

Muitas vezes negligenciados

Geralmente deixado a cargo

Não haver uma

Não serem contemplados no

Serem considerados implícitos

 Geralmente não é feita uma boa gestão

PROF. AUGUSTO FARNESE

 A cada ciclo fazer o mínimo necessário.

PROF. AUGUSTO FARNESE

 Processo iterativo e incremental.

 Liderança Técnica em Times Ágeis.

 Conceito de Preparado e Pronto.

 Revisão e Retrospectiva de Sprints.

 Tarefas com ”timebox”.

 Responsável deve atacar o problema.

 Alinhar o entendimento com a equipe.

 Contato frequente com o

 Identificar os riscos técnicos:

 Como melhorar arquitetura;

 Quais os riscos à frente.

 Deve-se ter grande alinhamento

 Usar os ritos ágeis para melhoria

PROF. AUGUSTO FARNESE

 Os 12 princípios por trás do manifesto.

Indivíduos e Interações Processos e Ferramentas

Software que funciona Documentação Abrangente

Colaboração com o Cliente Negociação de Contratos

Resposta a Mudanças Seguir um Plano

 Agilidade está nas atitudes do dia a dia.

 As definições arquiteturais também

PROF. AUGUSTO FARNESE

 Estratégias intencionais da arquitetura.

 Reações orgânicas das decisões de design.

Melhoram o design da solução,

Provê caminho para sincronização

Provê base técnica para uma

Ajuda desenvolvedores e arquitetos

Permite que a arquitetura evolua à

 Arquitetura evolui incremental e

PROF. AUGUSTO FARNESE

 Convivência entre antigo e novo.

 Estratégias para lidar com legado.

3 Geralmente não é fácil

 Fazer tudo novo.

 Evoluir o velho e fazer o novo.

 É importante definir a estratégia de

PROF. AUGUSTO FARNESE

Prof. Augusto Farnese

PROF. AUGUSTO FARNESE

PROF. AUGUSTO FARNESE

 O que é gestão de produtos.

 Entender o problema antes de pensar a solução.

 A arquitetura deve pensar o Problema.

 Devemos abraçar o mundo VUCA e

PROF. AUGUSTO FARNESE