• Nenhum resultado encontrado

Aula 11 - Arquitetura_Interface_Prototipo

N/A
N/A
Protected

Academic year: 2021

Share "Aula 11 - Arquitetura_Interface_Prototipo"

Copied!
78
0
0

Texto

(1)

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.com

(2)

Projeto 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

(3)

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.

(4)

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

(5)

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.

(6)

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.

(7)

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.

(8)

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.

(9)

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.

(10)

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?

(11)

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?

(12)

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.

(13)

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”.

(14)

Exemplos de Estilos Arquiteturais

 Cliente-Servidor;  “Em camadas”;

Baseado em repositório;

Orientado a eventos (publisher/subscriber);Transferência Representacional de Estado

(REST);

(15)
(16)

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.

(17)

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);

(18)

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.

(19)

Arquitetura de conjunto de ferramentas

CASE

(20)

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;

(21)

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.

(22)
(23)

Reflexão

 Qual e a Vantagem de uma Arquitetura Cliente Servidor?

(24)

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;

(25)

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.

(26)
(27)

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

(28)

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

(29)
(30)

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;

(31)

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;

(32)

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.

(33)
(34)

Gerenciador para um

Sistema Tempo Real

Comunicação entre o Controlador e os outros componentes pode Ser baseada em eventos, chamadas de procedimentos, etc.

(35)

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

(36)

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

(37)
(38)

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.

(39)
(40)

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

(41)
(42)

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.

(43)

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.

(44)

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:

(45)

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;

(46)

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.

(47)

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:

(48)

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

(49)

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.

(50)

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

(51)

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.

(52)

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.

(53)

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.

(54)

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.

(55)

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.

(56)

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:

(57)

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.

(58)

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.

(59)

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.

(60)

Caixinha de Ferramentas

 Visio;  Paint;  IDE;  iPlotz;  Cacoo;  Balsamiq;  Axure;

(61)

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.

(62)

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.

(63)

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

(64)

Vídeo

 https://www.youtube.com/watch?v=hB9bt

_dmlBQ

(65)

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

(66)

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

(67)
(68)
(69)
(70)
(71)
(72)
(73)

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

(74)
(75)
(76)

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

(77)

Referencias

 http://www.devmedia.com.br/engenharia- de-software-2-tecnicas-para-levantamento-de-requisitos/9151  http://www.lume.ufrgs.br/bitstream/handle /10183/80313/000881952.pdf?sequence=1  http://homepages.dcc.ufmg.br/~rprates/ge _vis/cap6_vfinal.pdf

(78)

Referências

Documentos relacionados

Outra informação obtida junto aos entrevistado quando mostrada uma representação esquemática da comunicação cartográfica de entidades mapeadas (Figura 03)

A segunda contribuição é explicitar que a aplicação desse método, mesmo que tratando de um recorte específico no processo histórico de formação para o trabalho simples e

No 1T21, o Fundo divulgou as seguintes transações ao mercado: (i) em 21/01/21, por meio do Comunicado ao Mercado³, informou sobre a liberação da quarta tranche do Especulativo

ensino superior como um todo e para o curso específico; desenho do projeto: a identidade da educação a distância; equipe profissional multidisciplinar;comunicação/interatividade

musicais entre os estudantes, no que se refere à interpretação, sem distinção de estilo, gênero e nacionalidade, desde que estejam ativos no IFPB. 4º - O Festival

 Esta abordagem pode trazer melhores resultados no caso em que o número de elementos das matrizes é muito elevado e em que uma decomposição simples baseada nos. resultados

MILHO PARA PIPOCA TIPO 1 - embalagem plástica íntegra rótulo com indicação do fabricante, produto, peso, ingredientes, data de fabricação, prazo de validade e

A seleção portuguesa feminina de andebol de sub-20 perdeu hoje 21-20 com a Hungria, na terceira jornada do Grupo C do Mundial da categoria, a decorrer em Koprivnica, na