A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Arquiteturas de Software Francilene Garcia Projeto I 2008.2.

Apresentações semelhantes


Apresentação em tema: "Arquiteturas de Software Francilene Garcia Projeto I 2008.2."— Transcrição da apresentação:

1

2 Arquiteturas de Software Francilene Garcia Projeto I

3 Conceitos Básicos

4 Um sistema computacional

5 Um sistema computacional isolado… No espaço, ninguém escuta o seu ?

6 Stakeholders… Arquiteto Operador CEO Fornecedor Técnico Desenvolvedor AdminSys Consumidor QA BillGates CEO Cliente

7 Outros sistemas… Cadastros Labs Estudantes Infra Rede Contabilidade Gerador de Relatórios Ativos

8 Oportunidades e riscos… Venda acelerada de sistemas Entrada na Bolsa Chega tarde ao mercado Venda fraca de sistemas Desempenho fraco Construção de imagem Impostos Mercado imaturo BillGates

9 Restrições e aspectos críticos… Sistema Operacional Padrões Políticas Legislação Processador + rápido Sistemas Legados Alta oferta de desenv. Java Falta desenv. de BD Ética e meio ambiente

10 É complicado.

11 Qual o papel da arquitetura? Leaning tower image from Gary Feuerstein. Other images from The Big Ball of Mud, by Yoder and Foote.

12 Ciclo de vida do desenvolvimento A arquitetura desempenha um papel vital na definição da estrutura do sistema, desde cedo no ciclo de vida do desenvolvimento The evolutionary delivery lifecycle model (Rapid Development, Steve McConnell) Arquitetura define a estrutura do sistema Primeira release libera o core do sistema

13 Vida útil do sistema A arquitetura antecipa decisões que afetam toda vida útil do sistema

14 Definições… Um sistema é um conjunto de partes …e formam um todo que atendem a expectativas As partes se relacionam entre si…

15 Alguns exemplos… Antes: Na engenharia, trabalha-se com muitos modelos. Um modelo é uma representação que abstrai detalhes menos essenciais, e pode ser manuseada de uma forma que o objeto real não permite.

16 Boletim Web (Blog) Uma arquitetura em 3-camadas – muito utilizada em sistemas client-server e web Disponibilidade Segurança

17 Processamento de imagem O processamento tipo pipeline é muito utilizado em sistemas de tempo real e embarcados Desempenho Portabilidade

18 Isto é tudo! Questões?

19 Referências e Leituras Recomendadas "An Introduction to Architecture." Chapter 1 of A Software Architecture Primer, by John Reekie and Rohan McAdam. "Architectural Analysis." Chapter 2 of A Software Architecture Primer, by John Reekie and Rohan McAdam. Jan Bosch, ``Design of Software Architectures,'' Chapter 2 of Design and Use of Software Architectures: Adopting and Evolving a Product-line Approach, pp Addison-Wesley, Alistair Cockburn, ``Introduction,'' Chapter 1 of Writing Effective Use Cases, pp Addison-Wesley, 2000.

20 Análise e Projeto Arquitetural

21 Arquitetura é arte? Necessidades do Cliente Arquitetura desejável Fatores contextuais Os clientes devem auxiliar no projeto da arquitetura desejável, sem esquecer os fatores contextuais

22 Fatores contextuais – para casas Clima Materiais disponíveis Portabilidade Riscos Atividades

23 Fatores contextuais? São exemplos de fatores. onstraints nablers isks OS-Z melhora a segurança OS-Z não é compatível OS-Z não tem tal facilidade

24 Tipos de fatores contextuais São buscados em vários lugares: –Mercado/concorrência –Empresas –Tecnologia –Políticas Padrão 3576 requer… A legislação restringe falhas … Esta janela de oportunidade… Uma versão atualizada de … A forte capacidade de desenvolvimento Java… O time de desenvolvimento da India…

25 Decisivos Mudança…! Estrutura organizacional Desempenho do time

26 Uso de narrativas Um caminho informal mas útil para descrever funcionalidades do sistema através de cenários Cria personagens e conta a estória Algumas vezes pode parecer levar à escrita de casos de uso Preciso de um editor que escute minhas palavras e gere um histórico com meus discursos…

27 Um exemplo de narrativa Pedro está interessado em comparar paisagens do litoral nordestino com praias da costa espanhola usando padrões de fotografia. Ele tem acumulado e classificado dados nos últimos cinco anos, exportando-os de forma que os dados possam ser manuseados por um pacote estatístico. Pedro é um pesquisador do INPE.

28 Requisitos funcionais Surgem das necessidades dos stakeholders Explicitam quais funcionalidades o sistema deve prover Abordagens variam: –Linguagem estruturada (análise de requisitos) –Casos de uso –Modelos formais –Estórias de Uso (XP1)

29 Requisitos não-funcionais Expressados na forma de atributos de qualidade A arquitetura deve identificar, analisar e suportar a implementação de atributos de qualidade

30 Atributos runtime Atributos runtime afetam a execução do sistema em produção Cenários devem ser descritos com foco em instâncias específicas da execução

31 Um acrônimo bem utilizado… sability eliability erformance ecurity Impacto de fatores humanos Taxa de falhas, modos, severidade, e recuperação Velocidade do process., utilização de recursos, tempo de resposta Integridade dos dados, confidencialidade, resistência a ataques São atributos usados para definir o guarda-chuva das qualidades.

32 Qualidades não ligadas à execução São mais ligadas à vida útil do sistema Cenários são expressados em termos de incidentes que ocorrem durante o desenvolvimento, deployment, ou operação do sistema

33 Outros acrônimos… aintainability estability eusability onfigurability calability volvability ntegrity

34 Algum outro atributo de qualidade? availability auditability modifiability feasibility compatibility backwards-compatibility standards- compliance continuity-of-view friendliness customizability learnability memorability enjoyability responsiveness schedulability verifiability analyzability reparability adaptability integrability interoperability predictability extensibility dependability safety portability survivability expendability expandability extensibility distributability flexibility

35 Performance Pode se manifestar de diferentes formas: –Latência –Rendimento –Eficiência de memória Diferentes métricas de desempenho devem ser aplicadas a diferentes partes do sistema

36 Usability Usabilidade apresenta vários aspectos: –Aprendizagem –Atratividade –Tempo para completar a tarefa –Taxa de erros Para um bom resultado, deve ser analisado por um perito em usabilidade

37 Reliability Um campo complexo: –Falhas de hardware/software –Mean time to failure (MTTF) –Mean time to repair (MTTR) Demandas por Reliability dependem de sua criticalidade: –Indesejável –Perda de receita –Perda de vida Availability = MTTF MTTF+MTTR

38 Reliability Conceito varia para sistemas diferentes: –Sistemas financeiros podem se tornar indisponíveis, MAS nenhum dado pode ser perdido –Sistemas de Telecom podem perder dados MAS devem se recuperar agilmente –Sistemas de controle devem manter o controle, em qualquer situação Capacidade de recuperação

39 Criticality Consequência do sistema de falha –Não-crítica Perturba a atividade –Baixa Perda de negóco, mas não séria –Média Perda de longo prazo para o negócio –Alta Prejuízo, perda de vida, etc.

40 Security Todo sistema trata de alguma maneira: –Ataque externo (network) –Fragilidade da política –Integridade dos dados Segurança é onerosa Técnicos especializados podem ajudar

41 Endereçando atributos de qualidade Narrativas (ou cenários) Comportamento Patterns (padrões) Estilos Táticas

42 Narrativas Uma narrativa ou cenário que reforça o atributo de qualidade buscado –Contexto –Ação –Resposta Deve ser mensurável! Preciso de um editor que escute minhas palavras e gere um histórico com meus discursos… a cada 15 minutos de fala deve ser gerado um documento

43 Performance A consulta no caixa eletrônico deve gerar um retorno em menos de 2 segundos.

44 Referências e Leituras Recomendadas "Architectural Design." Chapter 3 of A Software Architecture Primer, by John Reekie and Rohan McAdam. Michael Hirsch, ``Making RUP agile,'' OOPSLA 2002 Practitioners Reports, William J. Brown, Hays W. McCormick III, and Scott W. Thomas. ``One Size Fits All,'' in AntiPatterns in Project Management, pp John Wiley and Sons, Frederick P. Brooks Jr. The Design of Design. Turing Award Lecture, 2001.

45 Visões contempladas na arquitetura de software

46 Um elefante… Baseado numa fábula indiana. Uma cobra! Uma corda? É como um leque! Uma árvore! Uma parede! Um arpão!

47 Um sistema de software… Vamos ver o deployment E as atividades de tempo real? Quais as vantagens estratégicas ? Como vai funcionar a funcionalidade de mineração de dados?

48 Visão conceitual Execução Implementação Visões da arquitetura Uma visão expressa um aspecto particular da arquitetura Alguns autores recomendam a construção de várias visões… outros não… Domain-level responsibilities Estrutura Run-time Estrutura Build-time

49 Componentes e conectores Um componente relaciona um conjunto de responsabilidades A arquitetura conceitual estrutura o sistema em termos de responsabilidades no nível do domínio Exemplos de responsabilidades: PlayBackClipSequence SynchronizeWithVideo PrefetchClips Um conector indica a comunicação entre componentes

50 Interfaces externas Interfaces externas (incluindo sistemas legados) Algumas restrições físicas do sistema conhecidas Interfaces essenciais com hardware Nota: Um stakeholder não é um sistema externo!

51 Projetando uma arquitetura? Atributos de qualidade Requisitos do negócio Requisitos funcionais SRS

52 Não desista… Design é um processo iterativo. A cada passo, descobre-se mais sobre o problema, e mais ainda sobre a solução. Vamos iniciar com um procedimento simples…

53 1. Busque uma narrativa do sistema A Sapataria Gomes pretende ter um plano de propaganda utilizando os mecanismos tradicionais, mas que necessita de um site web para ser o local central no qual os clientes podem conhecer os modelos e ordenar calçados com medidas e estilos customizados. Eles também querem usar o site web como interface de entrada para o sistema financeiro. O gerente da Sapataria Gomes explicou: O que nós queremos é desenvolver um kit com informações básicas para envio aos nossos clientes e receber de volta o seu pedido. Nos últimos anos, nós aprendemos muito sobre como ofertar calçados customizados e montamos o kit. Assim que recebemos as medidas e preferências dos clientes, nós podemos fabricar qualquer sapato – todos customizados – aplicando padrões de material, cores e acabamentos!

54 2. Identifique conceitos chaves A Sapataria Gomes quer fazer publicidade utilizando meios convencionais, mas requerem um website como local central no qual os clientes podem obter informações sobre o kit base, entender os padrões existentes, e solicitar seu sapato customizado. Eles também querem usar o website como interface para o sistema financeiro. O Gerente da Sapataria Gomes disse: Queremos dissmeinar o kit base para nossos clientes e receber um retorno deles. … Nós podemos produzir qualquer sapato aplicando uma grande variedade de padrões …!

55 3. Refine os componentes Propaganda - conceito abstrato X Website - implementação ? Clientes - stakeholder Cliente do sistema contábil + Página personalizada Faixa de cliente Diversidade de produto Kit base Medidas históricas de clientes Sapato customizado Pedido do sapato Sistema contábil – sistema externo Acct I/F Sapato produzido – sistema externo Shoe production Padrões e acabamentos – parte do Kit base

56 4. Projete e conecte HTTP Acct I/F Pedido Página públicaPágina person. Cliente solicita Variedade Produtos Kit base Templates Produção calçados Medidas dos clientes

57 Este é o ponto de partida Outras iterações deverão melhorar a arquitetura de forma a melhor mapear as funcionalidades e os atributos de qualidade

58 Refine a arquitetura Acrescente ou quebre componentes Explicite melhor as responsabilidades Identifique os estereótipos Crie os modelos de dados Explore os comportamentos MuitoPesada Um componente é um conjunto de responsabilidades relacionadas. Quebre o componente se as responsabilidades não se relacionam entre si … Devem ser contempladas as demandas de desempenho e disponibilidade

59 Um estereótipo indica que o componente (uma classe) possui algumas propriedades ou atributos. Estereótipos conceituais Um componente tem algum tipo de responsabilidade especial? –Interface –Armazenamento persistente –Tempo de resposta

60 Um exemplo de estereótipo Um diagrama que sintetiza aspectos da arquitetura. É útil para auxiliar na compreensão de aspectos mais complexos.

61 Arquitetura da Sapataria Gomes com estereótipos Public Page Personal Page Customer accounts Customer meas. Product range Order shoes Customise shoes Shoe production Browse products Templates Acct I/F HTTP

62 Modelos de dados Um modelo de dados captura a estrutura essencial do dado –Dados e conectores –Dados persistentes Student ID : integer Subject ID : integer points : integer Course name : String enrolled-in currently-taking 0..*

63 O que é um comportamento Um sistema envolve funcionalidades, uma estrutura e comportamentos Comportamento reúne um conjunto de ações que o sistema executa Podem ser explorados da seguinte forma: – Papel a ser desempenhado – Casos de Uso – Diagramas de sequência

64 Como podemos explorar mais? Agent AnalyzerDatabase Visualization toolkit Web UI Visualizer Viz UI Update manager What to search forDiscovered data Analyzed data Data query Requested data Viz configuration Visualization data Webviz data Viz structuring Viz rendering Update throttle O sistema deve ter um comportamento em resposta a uma atividade definida nas narrativas

65 Explore eventos das narrativas Pedro trabalha na UFCG. Ele prefere escolher o estilo de calçados. Ele ouviu falar da Sapataria Gomes e quer experimentar. Ele navega no site e escolhe alguns padrões. Ele prefere algo em tons claros de um couro liso num solado confortável. Ele preenche dados com suas preferências. Ele não quer fazer o pedido final ainda, ele deixa o pedido numa lista de produtos desejados. browseWebsite customiseShoe saveToWishList

66 Eventos definem mapas de casos de uso Casos de uso ajudam a visualizar o fluxo –Mostra a sequência de atividades –Atividade responde a um evento –Cada vez que um evento se dá, exercita-se uma responsabilidade CompB Data CompC CompA RespA1 EventName RespB3 RespC2 Mapas de caso de uso auxiliam a compreender o comportamento macro

67 Notação casos de uso Continuation AND-fork OR-fork SEQ-fork

68 Sapataria Gomes (1) Public Page Personal Page Customer accounts Customer meas. Product range Order shoes Customise shoes Shoe production Browse products Templates Acct I/F HTTP BrowseRange

69 Sapataria Gomes (2) Public Page Personal Page Customer accounts Customer meas. Product range Order shoes Customise shoes Shoe production Browse products Templates Acct I/F HTTP customiseShoe Uma conexão é necessária aqui?

70 O que não fazer… Um AntiPadrão que ocorre frequentemente nas arquiteturas de software… Um anti-padrão descreve uma solução indesejável para um conjunto de fatores contextuais recorrentes. Também ajuda a descrever como refatorar tal situação e obter uma solução desejável.

71 Versão object-oriented Uma classe controller rodeada por classes simples Um procedimento comum no mundo OO Obtida de requisitos que ditam soluções procedurais Um resultado pobre em termos de evolução Everything Else Simple Class A Simple Class B Simple Class C Simple Class D Simple Class E

72 Um aplicação complexa ou componente lógico rodeado por componentes de interface ou dados Levam nomes como controller ou manager Indicam a incapacidade de decompor o sistema em função das responsabilidades retiradas do domínio Versão arquitetural Courses Personal page System controller User data Course data

73 Refatoramento Re-design object-oriented –Rever comportamentos –Identificar lumps –Agregar classes simples relacionadas entre si Re-design arquitetural –Identificar todas as responsabilidades –Obter múltiplos componentes baseados nas responsabilidades Ou ainda: –Jogar fora e reiniciar AntiPatterns compilam experiências do mundo real na forma de problemas recorrentes & indicam soluções

74 Referências e Leituras Recomendadas "Conceptual Architecture." Chapter 4 of A Software Architecture Primer, by John Reekie and Rohan McAdam. Phillippe Kruchten, " Architectural Blueprints The 4+1 View Model of Software Architecture", in IEEE Software 12 (6) November 1995, pp R. J. A. Buhr, A. Hubbard,"Use Case Maps for Engineering Real Time and Distributed Computer Systems: A Case Study of an ACE- Framework Application", in IEEE 1996.


Carregar ppt "Arquiteturas de Software Francilene Garcia Projeto I 2008.2."

Apresentações semelhantes


Anúncios Google