Engenharia de Software
Projeto de Arquitetura; Projeto de Interface; Prototipação. Capitulo 8,9 e 10 da PLT https://sites.google.com/site/thiagoaalves/ thiago.augusto2@anhanguera.comProjeto de Arquitetura
O processo de projeto para identificar os subsistemas que constituem um sistema e o framework para controle e
comunicação deste subsistema é
denominado projeto de arquitetura. A saída desse processo de projeto é uma
Projeto de Arquitetura
É o primeiro estágio do processo de projeto de sistema.
Representa a ligação entre os processos de especificação e de projeto.
É frequentemente conduzido em paralelo com algumas atividades de especificação. Envolve a identificação dos componentes
principais do sistema e suas comunicações.
Projeto de Arquitetura
Vantagens da arquitetura explícita
◦ Comunicação de stakeholder
A arquitetura pode ser usada como um foco de
discussão pelos stakeholders do sistema.
◦ Análise de sistema
Se há possibilidade de o sistema atender a seus
requisitos não funcionais.
◦ Reuso em larga escala
A arquitetura pode ser reusável em uma variedade
Características de arquitetura e de
sistema
Desempenho
◦ Localizar operações críticas e minimizar
comunicações. Usar componentes de alta ao invés de baixa granularidade.
Proteção
◦ Usar uma arquitetura em camadas com itens críticos nas camadas mais internas.
Segurança
◦ Localizar características críticas de segurança em um pequeno número de subsistemas.
Características de arquitetura e de
sistema
Disponibilidade
◦ Incluir componentes redundantes e mecanismos para tolerância à falhas.
Facilidade de manutenção
◦ Usar componentes substituíveis e de baixa granularidade.
Conflitos de arquitetura
1. O uso de componentes de alta granularidade
aprimora o desempenho mas diminui a facilidade de manutenção.
2. A introdução de dados redundantes aprimora
a disponibilidade, mas torna a proteção mais difícil.
3. Ao localizar características relacionadas à
segurança, geralmente significa maior
comunicação e, por essa razão, o desempenho é degradado.
Estruturação de Sistema
Está relacionado à decomposição do sistema
em subsistemas que interagem.
O projeto de arquitetura é normalmente
expresso como um diagrama de blocos que apresentam uma visão geral da estrutura do sistema.
Modelos mais específicos que mostram
como os subsistemas compartilham dados, como são distribuídos e como se
comunicam com os outros, também podem ser desenvolvidos.
Decisões de projeto de arquitetura
Projeto de arquitetura é um processo criativo cujas atividades diferem
radicalmente dependendo do tipo de sistema que está sendo desenvolvido.
Contudo, uma série de decisões comuns afetam todos os processos de projeto.
Decisões de projeto de arquitetura
Existe uma arquitetura genérica de aplicação que possa ser usada?
Como o sistema será distribuído? Quais estilos de arquitetura são
apropriados?
Qual será a abordagem fundamental usada para estruturar o sistema?
Decisões de projeto de arquitetura
Como o sistema será decomposto em módulos?
Qual estratégia deve ser usada?
Como o projeto de arquitetura será avaliado?
Como a arquitetura do sistema deve ser documentada?
Projeto de Arquitetura
Reuso de arquitetura;
Sistemas do mesmo domínio
frequentemente têm arquiteturas
similares que refletem os conceitos de domínio.
As linhas do produto de aplicação são construídas em torno de um núcleo de arquitetura com variantes que satisfazem requisitos específicos de clientes.
Estilos Arquiteturais
A arquitetura de um sistema pode aderir a um
ou mais estilos arquiteturais:
◦ Um estilo define os tipos de elementos que podem aparecer em uma arquitetura e as regras que regem a sua interconexão;
Esses estilos pode simplificar o problema de
definição de arquiteturas de Sistema;
A maioria dos sistemas de grande porte adere
a vários estilos;
Estilos arquiteturais = “modelos arquiteturais”.
Exemplos de Estilos Arquiteturais
Cliente-Servidor; “Em camadas”;
Baseado em repositório;
Orientado a eventos (publisher/subscriber); Transferência Representacional de Estado
(REST);
Estilos Arquiteturais e Escolhas de
Projeto
Um estilo arquitetural representa um
conjunto de escolhas de projeto:
◦ Conjunto de características comuns a diversos sistemas nos quais as mesmas escolhas foram feitas;
Padrões arquiteturais;
◦ Um sistema aderente a determinado estilo “ganha" as características inerentes a ele;
Estilos podem ser usados para descrever uma
determinada arquitetura:
◦ Foco nas soluções de projeto e não em sua documentação.
Organização de sistema
Reflete a estratégia básica que é usada para estruturar um Sistema.
Exemplos:
◦ O estilo de repositório de dados compartilhados;
◦ Estilo de serviços e servidores compartilhados;
◦ Estilo de máquina abstrata ou em camadas;
◦ Orientado a objetos (ou Objetos Distribuídos);
Estilo de repositório
Sistemas cujas partes precisam trocar dados com frequência:
◦ Dados compartilhados podem ser mantidos em um banco de dados central e acessados por todos os subsistemas;
◦ Cada subsistema mantém seu próprio banco de dados e passa dados para outros
subsistemas:
Podem usar uma abstração de repositório centralizado; Implementação distribuída.
Arquitetura de conjunto de ferramentas
CASE
Características do Estilo Arquitetural de
Repositório
Vantagens
◦ É uma maneira eficiente de compartilhar grandes quantidades de dados;
◦ Dados aderem a uma representação comum;
◦ Simplifica a projeto de aplicações fortemente baseadas em dados;
Tanto para troca de informações quanto para armazenamento;
Desvantagens
◦ Os subsistemas devem estar de acordo com um modelo de dados padronizado;
◦ A evolução de dados é difícil e dispendiosa;
Estilo Cliente-Servidor
Mostra como dados e processamento são distribuídos por uma variedade de
components;
Servidores independentes que fornecem serviços tais como impressão, transferência de arquivos, gerenciamento de dados, etc. Clientes utilizam esses serviços
Clientes e servidores normalmente se comunicam através de uma rede:
◦ Diversas tecnologias de comunicação são possíveis.
Reflexão
Qual e a Vantagem de uma Arquitetura Cliente Servidor?
Características do Estilo
Cliente-Servidor
Vantagens
◦ Separação de interesses
◦ Inerentemente distribuído:
Balanceamento de carga, tolerância a falhas;
◦ É fácil adicionar novos servidores ou atualizar servidores existentes.
Desvantagens
◦ Gerenciamento redundante em cada servidor;
◦ Nenhum registro central de nomes e serviços – pode ser difícil descobrir quais servidores e
serviços estão disponíveis;
Modelo de Máquina Abstrata
(Em Camadas)
Organiza o sistema em um conjunto de camadas (ou máquinas abstratas):
◦ Cada uma fornece um conjunto de serviços;
◦ Cada camada é cliente da camada subjacente.
Generalização do estilo Cliente-Servidor:
◦ Não precisa ser distribuído.
Apóia o desenvolvimento incremental dos subsistemas em camadas diferentes:
◦ Ex. Se mudarmos a camada de negócios, só as camadas acima precisam ser modificadas.
Características do Estilo em
Camadas
Vantagens ◦ Facilidade de compreensão ◦ Facilidade de manutenção ◦ Desenvolvimento independente Desvantagens ◦ Duplicação de funcionalidade◦ Às vezes é difícil estruturar um sistema através de camadas
É comum que a estruturação seja violada Camadas relaxadas são necessárias
Estilo Arquitetural de Objetos
Sistema como um conjunto de objetos
fracamente acoplados e com interfaces bem definidas:
◦ Cada objeto oferece um conjunto de serviços; No nível arquitetural, é frequentemente
empregado na construção de sistemas
distribuídos:
◦ Objetos distribuídos;
Uma implementação OO não implica em uma
Características do Estilo Arquitetural
de Objetos
Vantagens
◦ Objetos são fracamente acoplados devido ao uso de interfaces;
◦ Linguagens de implementação orientada a objeto são amplamente usadas;
Desvantagens
◦ Mudanças de interface têm alto impacto;
◦ Não envolve restrições topológicas, o que pode dificultar a manutenção;
Fluxo de Controle
Estilos arquiteturais relacionados com o fluxo de controle entre os componentes arquiteturais;
Controle centralizado:
◦ Um subsistema tem responsabilidade global pelo controle e inicia e para outros sistemas;
Controle baseado em eventos:
◦ Cada componente responde a eventos gerados por outros subsistemas;
Controle Centralizado
Um componente é responsável pelo
gerenciamento da execução de outros componente;
O estilo Chamada-Retorno
◦ Controle se inicia no topo de uma hierarquia de subrotinas e move-se para baixo na hierarquia.
◦ Pode ser sequencial ou concorrente; O estilo de Gerenciador
◦ Aplicável a sistemas concorrentes e de tempo real
◦ Um componente controla a parada, o início e a coordenação de outros processos de Sistema.
Gerenciador para um
Sistema Tempo Real
Comunicação entre o Controlador e os outros componentes pode Ser baseada em eventos, chamadas de procedimentos, etc.
Sistemas orientados a eventos
Dirigidos por eventos gerados externamente
◦ O timing dos eventos está fora do controle dos componentes que os processam;
Estilo Publisher/Subscriber
◦ Eventos são transmitidos a todos os components;
◦ Qualquer componente interessado pode respondê-los;
Estilo Orientado a Interrupções
◦ Usado em sistemas de tempo real ;
◦ Interrupções são detectadas por tratadores e passadas por outro componente para
Modelo Publisher/Subscriber
É efetivo na integração de componentes em computadores diferentes em uma rede:
◦ Desacoplamento espacial e temporal;
◦ Componentes não sabem se um evento será tratado e nem quando será;
Alguns componentes (publishers) publicam
eventos;
Componentes (subscribers) registram interesse
em eventos específicos e podem tratá-los; A política de controle não é embutida no
Estilo Orientado a Interrupções
Usado em sistemas de tempo real onde a resposta rápida para um evento é essencial; Cada tipo é associado a uma localização da
memória:
◦ Uma chave de hardware causa a transferência de controle para um tratador;
Permite respostas rápidas, mas é complexo para programar e difícil de validar.
Arquiteturas de Referência
Derivadas de um estudo de domínio de
aplicação, ao invés de sistemas existentes;
Podem ser usadas como base para a
implementação de sistemas ou comparação de sistemas diferentes:
◦ Atua como um padrão com relação ao qual os sistemas podem ser avaliados.
Exs.
◦ Modelo OSI para sistemas de comunicação;
◦ Organização tradicional de compiladores em
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Podemos pegar o levantamento de requisitos como uma base para o levantamento das necessidades dos usuários para interfaces.
Alguns detalhes do próprio sistema vão nos fornecer detalhes sobre como serão as interfaces do sistema.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Em uma analise de requisitos inicial só de conseguir saber quais informações o
usuário gostaria que fossem apresentadas já conseguimos ter algumas ideias para a construção da interface.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
O início para toda a atividade de desenvolvimento de software é o
levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos.
Sommerville (2003) propõe um processo genérico de levantamento e análise que contém as seguintes atividades:
Levantamento das Necessidades dos
Usuários para Design de Interfaces
◦ Compreensão do domínio: Os analistas devem desenvolver sua compreensão do domínio da aplicação;
◦ Coleta de requisitos: É o processo de interagir com os stakeholders do sistema para descobrir seus
requisitos. A compreensão do domínio se desenvolve mais durante essa atividade;
◦ Classificação: Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes;
◦ Resolução de conflitos: Quando múltiplos stakeholders estão envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por objetivo solucionar esses conflitos;
Levantamento das Necessidades dos
Usuários para Design de Interfaces
◦ Definição das prioridades: Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. Esse estágio
envolve interação com os stakeholders para a definição dos requisitos mais importantes;
◦ Verificação de requisitos: Os requisitos são
verificados para descobrir se estão completos e consistentes e se estão em concordância
com o que os stakeholders desejam do sistema.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
O levantamento e análise de
requisitos é um processo iterativo, com
uma contínua validação de uma atividade para outra, conforme exemplificado pela Figura:
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Técnicas de Levantamento de
Requisitos
As técnicas de levantamento de requisitos têm por objetivo superar as dificuldades relativas a esta fase. Todas as técnicas
possuem um conceito próprio e suas
respectivas vantagens e desvantagens, que podem ser utilizadas em conjunto pelo
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Levantamento orientado a pontos de vista
Para qualquer sistema, de tamanho médio ou
grande, normalmente há diferentes tipos de
usuário final. Muitos stakeholders têm algum tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo para um sistema relativamente
simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes
pontos de vista a respeito de um problema ‘vêem’ o problema de modos diferentes. Contudo, suas perspectivas não são inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
As abordagens orientadas a ponto de vista,
na engenharia de requisitos, reconhecem
esses diferentes pontos de vista e os utilizam para estruturar e organizar o processo de
levantamento e os próprios requisitos. Uma importante capacidade da análise orientada a pontos de vista é que ela reconhece a
existência de várias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por
Levantamento das Necessidades dos
Usuários para Design de Interfaces
O método VORD (viewpoint-oriented
requirements definition – definição de requisitos orientada a ponto de vista) foi projetado
como um framework orientado a serviço para o levantamento e análise de requisitos.
A primeira etapa da análise de ponto de
vista é identificar os possíveis pontos de vista. Nessa etapa os analistas se reúnem com os stakeholders e utilizam a abordagem de brainstorming para identificar os serviços em potencial e as entidades que interagem com o sistema.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
A segunda etapa é a estruturação de pontos
de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia.
Serviços comuns estão localizados nos níveis mais altos da hierarquia e herdados por
pontos de vista de nível inferior.
A etapa de documentação do ponto de vista
tem por objetivo refinar a descrição dos pontos de vista e serviços identificados.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
O mapeamento de sistema conforme
ponto de vista envolve identificar objetos em um projeto orientado a objetos,
utilizando as informações de serviço que estão encapsuladas nos pontos de vista.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Prototipagem
Protótipo tem por objetivo explorar aspectos
críticos dos requisitos de um produto,
implementando de forma rápida um pequeno
subconjunto de funcionalidades deste produto. O protótipo é indicado para estudar as alternativas de interface do usuário; problemas de
comunicação com outros produtos; e a viabilidade de atendimento dos requisitos de desempenho. As técnicas utilizadas na elaboração do protótipo são várias: interface de usuário, relatórios textuais, relatórios gráficos, entre outras.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Alguns dos benefícios do protótipo são as
reduções dos riscos na construção do
sistema, pois o usuário chave já verificou o que o analista captou nos requisitos do
produto. Para ter sucesso na elaboração dos protótipos é necessária a escolha do
ambiente de prototipagem, o entendimento dos objetivos do protótipo por parte de
todos os interessados no projeto, a
focalização em áreas menos compreendidas e a rapidez na construção.
Levantamento das Necessidades dos
Usuários para Design de Interfaces
Prototipagem e uma das ferramentas que mais auxilia os analistas com relação ao Design de Interfaces.
Mas cuidado ao utiliza-la, ela pode gerar grandes expectativas por parte dos
clientes, veja alguns exemplos de como devem ser as interfaces prototipadas:
Levantamento das Necessidades dos
Usuários para Design de Interfaces
◦ Devem apresentar somente a ideia de como a interface vai ser;
◦ Devem demostrar aonde estarão as informações, botões, menus e janelas;
◦ Devem permitir que o usuário consiga entender o contexto geral da interface;
◦ Devem permitir que o usuário consiga ter uma noção geral de toda a informação e contexto.
Extra – Wireframe
Wieframe é um desenho básico, como um
esqueleto, que demonstra de forma direta a arquitetura de como o objeto (interface,
página da internet, modelo, etc.) final será de acordo com as especificações relatadas.
Ele é elaborado para organizar os elementos
que entrarão na composição do projeto final, no entanto, ele deve ser feito da maneira
mais simples possível, mostrando apenas o essencial, como uma espécie de rascunho, sem cores ou imagens.
Extra – Wireframe
O objetivo do Wireframe é auxiliar o desenvolvedor no entendimento dos
requisitos que foram recolhidos junto ao cliente com relação as funções e objetos que um sistema (mas não somente
relacionado a informática ou internet,
pode ser um objeto, modelo, etc.) deverá conter.
Caixinha de Ferramentas
Visio; Paint; IDE; iPlotz; Cacoo; Balsamiq; Axure;Protótipo de Papel
A construção de protótipos em papel é uma técnica clássica de grande aceitação no meio dos especialistas em projetos de interfaces de usuário devido à sua
simplicidade, ao seu baixo custo e por ser bastante efetiva.
Protótipo de Papel
Ela consiste em esboçar telas e objetos de interação (de acordo com o projeto de interação proposto) em papéis no tamanho real esperado para cada um.
Durante uma sessão de teste o esboço da janela principal é apresentado e é dada
uma tarefa típica para ser executada pelo participante.
Protótipo de Papel
Com um dedo o participante aponta e toca no esboço para indicar onde ele clicaria ou relata com que informação
preencheria um particular campo de uma caixa de diálogo ou de um formulário
Vídeo
https://www.youtube.com/watch?v=hB9bt
_dmlBQ
Exemplo
Vamos Pensar nos seguintes Requisitos e vamos desenvolver as
interfaces/protótipos para cobrir os requisitos.
Uma faculdade de EAD deseja
desenvolver um sistema para ser utilizado pelos professores e alunos. Inicialmente este sistema deve trabalhar com os
Exemplo
1. O sistema deve possuir um Calendário para o
aluno se situar com relação as suas atividades;
2. O sistema deve demonstrar as datas das
atividades que devem ser realizadas bem como a disciplina que ela pertence;
3. O sistema deve permitir a realização de provas
online. As provas obrigatoriamente são de múltipla escolha;
4. O sistema deve permitir que os alunos possam
ver suas notas junto com as frequências;
5. O sistema deve deixar o material disponível.
Este material e composto tanto por uma apostila eletrônica, quanto por vídeo aulas;
6. O Sistema deve permitir que os alunos possam
Exercício
Desenhe os Layout/Protótipos para atender os seguintes requisitos:
O Sistema deve permitir que o professor realize o cadastro das notas do alunos;
O Sistema deve permitir que o professor posso enviar mensagens para todos os
Referencias
SOMMERVILLE, Ian (org.). Engenharia
de Software. 9ª ed. São Paulo:
PEARSON, 2011. http://www.cic.unb.br/~genaina/ES/Aulas/ CAP11.pdf http://www.devmedia.com.br/arquitetura- de-software-atributos-para-decisoes-do-projeto-arquitetural/16121 http://www.devmedia.com.br/arquitetura- de-software-desenvolvimento-orientado-para-arquitetura/8033