Arquitetura - Aula 03

Prévia do material em texto

<p>Arquitetura de</p><p>Software</p><p>02/2024</p><p>Aula 03</p><p>Professores:</p><p>Cristiano de Macêdo Neto e</p><p>Rodrigo Couto e Silva</p><p>Roteiro</p><p>• Conceitos de Arquitetura de Software</p><p>• O Processo de Arquitetura de Software</p><p>Um pouco de História</p><p>(Evolução do Custo do Software)</p><p>• Muitos e muitos anos atrás ...</p><p>Um pouco de História</p><p>(Evolução do Custo do Software)</p><p>• Uma década depois</p><p>Um pouco de História</p><p>(Evolução do Custo do Software)</p><p>• Duas décadas depois</p><p>Um pouco de História</p><p>(Evolução do Custo do Software)</p><p>• Três décadas depois</p><p>Um pouco de História</p><p>(Evolução do Custo do Software)</p><p>• Atualmente</p><p>Um pouco de História</p><p>(Evolução da Complexidade e Tamanho)</p><p>• Muitos e muitos anos atrás ...</p><p>Um pouco de História</p><p>(Evolução da Complexidade e Tamanho)</p><p>• Atualmente</p><p>Um pouco de História</p><p>(Evolução da Ambiente de Desenvolvimento)</p><p>Um pouco de História</p><p>(Evolução da Ambiente de Desenvolvimento)</p><p>Um pouco de</p><p>História</p><p>(Evolução da</p><p>utilização de</p><p>Software)</p><p>Leis de Lehman</p><p>• Mudança contínua:</p><p>o Um software deve ser continuamente adaptado, caso contrário se torna progressivamente</p><p>menos satisfatório.</p><p>• Complexidade crescente:</p><p>o À medida que um software é alterado, sua complexidade cresce, a menos que um trabalho</p><p>seja feito para mantê-la ou diminuí-la.</p><p>• •Auto-regulação:</p><p>o O processo de evolução de software é auto-regulado próximo à distribuição normal com</p><p>relação às medidas dos atributos de produtos e processos, ou seja, atributos como tamanho,</p><p>tempo entre versões e números de defeitos variam pouco de uma versão para outra.</p><p>Leis de Lehman</p><p>• Conservação da estabilidade organizacional ou saturação:</p><p>o A não ser que mecanismos de retro-alimentação tenham sido ajustados de maneira</p><p>apropriada, a taxa média de atividade global efetiva num software em evolução tende a se</p><p>manter constante durante o tempo de vida do produto.</p><p>• Conservação da Familiaridade:</p><p>o De maneira geral, a taxa de crescimento incremental e taxa crescimento a longo prazo tende a</p><p>declinar.</p><p>• Crescimento contínuo:</p><p>• O conteúdo funcional de um software deve ser continuamente aumentado durante seu tempo</p><p>de vida para manter a satisfação do usuário.</p><p>Leis de Lehman</p><p>• Qualidade decrescente:</p><p>• A qualidade do software será entendida como declinante a menos que</p><p>o software seja rigorosamente adaptado às mudanças no ambiente</p><p>operacional.</p><p>• Sistema de Retro-alimentação:</p><p>• Processos de evolução de software são sistemas de retro-alimentação</p><p>em múltiplos níveis, em múltiplos laços (loops) e envolvendo múltiplos</p><p>agentes.</p><p>Manutenção de Softwares</p><p>• As mudanças de software são inevitáveis e causadas</p><p>por:</p><p>oNovos requisitos emergem quando o SW é usado</p><p>oO ambiente do negócio muda</p><p>oErros devem ser reparados</p><p>oNovo equipamento deve ser incorporado</p><p>oO desempenho ou fiabilidade podem ser melhorados</p><p>Reflexão</p><p>• “Grandes sistemas de software nunca são completados;</p><p>eles simplesmente continuam evoluindo” [Lehman]</p><p>Software para Locadora de Veículos</p><p>• Características</p><p>oLocadora de pequeno porte</p><p>oSem filiais</p><p>oSistema de locação apenas presencial</p><p>• Conseguimos conceber um sistema?</p><p>Software para Locadora de Veículos</p><p>• Requisitos</p><p>oCRUD para clientes, CRUD para carros, controle de locações e um</p><p>pequeno controle de caixa</p><p>oSistema desktop com interface com o usuário simples.</p><p>oMonousuário, baixa carga.</p><p>• Fácil concepção!</p><p>Software para Locadora de Veículos</p><p>• Pequena expansão: 1 filial</p><p>o Tudo que havia antes + Locação distribuída com entrega em outra</p><p>unidade</p><p>• Conseguimos conceber um sistema?</p><p>Software para Locadora de Veículos</p><p>• Requisitos aumentam</p><p>oCRUD sincronizado</p><p>oCadastro único de carros e clientes</p><p>oConsistência, tolerância a falhas e desempenho se tornam</p><p>preocupações</p><p>Software para Locadora de Veículos</p><p>Design de Software</p><p>Design de Software</p><p>• O processo de design pode ser descrito como o processo de</p><p>escolha da representação de uma solução a partir de várias</p><p>alternativas, dadas as restrições que um conjunto de objetivos</p><p>envolve.</p><p>Design de Software</p><p>Objetivo de Design</p><p>• Aquilo que se pretende alcançar para resolver as</p><p>necessidades do cliente</p><p>• Em Design de Software os objetivos são traduzidos em:</p><p>oRequisitos Funcionais</p><p>▪ O que o sistema faz para alcançar os objetivos do cliente</p><p>oRequisitos Não Funcionais</p><p>▪ Também chamado de atributo de qualidade</p><p>Níveis do Design de Software</p><p>• De acordo com o SWEBok há dois níveis conceituais:</p><p>o Design de alto nível (ou arquitetural)</p><p>▪ Descreve como o software é decomposto e organizado em módulos e suas relações</p><p>▪ Objetiva atributos de qualidade</p><p>o Design de baixo nível (ou detalhado)</p><p>▪ Descreve o comportamento específico em e detalhes dos módulos que compõem o design arquitetural</p><p>▪ Descrição para construção (implementação) do sistema</p><p>Software para Locadora de Veículos</p><p>E a Localiza?</p><p>• Percebem o tamanho do problema?</p><p>o Requisitos de qualidade difíceis de serem definidos</p><p>o Requer participação de todos que conhecem as necessidades do sistema</p><p>o Solução extremamente complexa</p><p>o Requer trabalho conjunto</p><p>o Requer comunicação de qualidade</p><p>o Requer experiência</p><p>o Requer liderança</p><p>o Solução de grande porte, difícil de organizar e documentar!</p><p>o Requer documentação completa</p><p>Arquitetura de Software</p><p>• Desde sua primeira menção em um relatório técnico da década</p><p>de 1970 (intitulado Software Engineering Tecnhiques), diversos</p><p>autores se propuseram a definir o termo Arquitetura de software.</p><p>oPercebe-se a necessidade de detalhar requisitos de qualidade</p><p>Arquitetura de Software</p><p>• Arquitetura de software é, simplesmente, um modelo conceitual</p><p>que facilita a transição de requisitos para a implementação.</p><p>Merson [2007]</p><p>Arquitetura de Software</p><p>Perry e Wolf [92]</p><p>Arquitetura = {Elementos, Organização, Decisões}</p><p>• Elementos e sua organização são definidos por</p><p>decisões tomadas para atender objetivos e restrições.</p><p>Perry e Wolf [92]</p><p>Arquitetura de Software</p><p>Perry e Wolf [92]</p><p>• Onde os elementos podem ser:</p><p>oElementos de processamento</p><p>▪ Usam ou transformam informação</p><p>oElementos de dados</p><p>▪ informação em si</p><p>oElementos de conexão</p><p>▪ interligam elementos de qualquer tipo</p><p>Arquitetura de Software</p><p>Perry e Wolf [92]</p><p>• E a organização dita as relações que possuem</p><p>propriedades e restringem como os elementos devem</p><p>interagir de forma a satisfazer os objetivos do sistema.</p><p>Arquitetura de Software</p><p>Garlan e Shaw [93]</p><p>• A arquitetura de software se torna necessária quando o</p><p>tamanho e a complexidade dos sistemas de software</p><p>crescem.</p><p>• O problema de se construir sistemas vai além da</p><p>escolha dos algoritmos e estruturas de dados certos.</p><p>• Envolve também decisões sobre as estruturas que</p><p>formarão o sistema</p><p>Arquitetura de Software</p><p>Garlan e Shaw [93]</p><p>• Aspectos Importantes da definição:</p><p>o São explícitos em quando devemos aplicar conhecimentos de arquitetura de</p><p>software</p><p>▪ Grandes sistemas.</p><p>o São claros na separação de tarefas entre design detalhado e design</p><p>arquitetural</p><p>o Citam que o processo de design da arquitetura precisa se preocupar com</p><p>atributos de qualidade do sistema.</p><p>▪ Exemplo: alcançar escalabilidade ou desempenho.</p><p>Arquitetura de Software</p><p>Bass et al [2003]</p><p>“A arquitetura de um programa ou de sistemas</p><p>computacionais é a estrutura ou estruturas do sistema,</p><p>a qual é composta de elementos de software, as</p><p>propriedades externamente visíveis desses elementos,</p><p>e os relacionamentos entre eles.”</p><p>Arquitetura de Software</p><p>Bass et al [2003]</p><p>• Essa definição enfatiza</p><p>oO papel da abstração na arquitetura</p><p>oA importância das múltiplas visões arquiteturais</p><p>oOs elementos de software como peças fundamentais</p><p>Arquitetura de Software</p><p>Bass et al [2003]</p><p>• Exemplo: Aplicação de WebMail – Visão 1</p><p>oDivisão em partes funcionais</p><p>▪ módulo responsável por verificar periodicamente no servidor SMTP se há novas mensagens para</p><p>cada usuário</p><p>▪ módulo responsável por salvar, buscar, guardar mensagens do usuário</p><p>▪ módulo responsável por guardar as preferências do usuário, etc.</p><p>▪ Todos os módulos têm métodos e propriedades disponíveis a outras</p><p>partes.</p><p>Arquitetura de Software</p><p>Bass et al [2003]</p><p>• Exemplo: Aplicação de WebMail – Visão 2</p><p>oProcessos executando e se comunicando em máquinas diferentes.</p><p>▪ O browser se comunica usando o protocolo HTTPS com um servidor de aplicações, que contém a</p><p>lógica do negócio (e os módulos).</p><p>▪ O servidor de aplicações, por sua vez, se comunicará com um SGBD usando</p><p>JDBC.</p><p>Arquitetura de Software</p><p>Padrão ISO/IEEE 1471-2000</p><p>“Arquitetura é a organização fundamental de um sistema</p><p>incorporada em seus componentes, seus</p><p>relacionamentos com o ambiente, e os princípios que</p><p>conduzem seu design e evolução.”</p><p>Objetivos da</p><p>Arquitetura de Software</p><p>• Principal</p><p>oAtingir a qualidade desejada pelos interessados no sistema.</p><p>• Secundária</p><p>oGuiar as atividades de desenvolvimento de software, para que se</p><p>possa satisfazer o comportamento esperado do software</p><p>O Processo de</p><p>Arquitetura de Software</p><p>• A organização do processo de Arquitetura de Software</p><p>se dá através da definição de atividades e papéis a</p><p>serem desempenhados.</p><p>O Processo de</p><p>Arquitetura de Software</p><p>• As principais atividades do processo de Arquitetura de</p><p>software compreendem em:</p><p>oElaboração do modelo de negócio,</p><p>oEntendimento dos requisitos,</p><p>oCriação e escolha da arquitetura,</p><p>oRepresentação e divulgação da arquitetura,</p><p>o Implementação baseada na arquitetura</p><p>oAnálise ou avaliação da arquitetura.</p><p>O Processo de</p><p>Arquitetura de Software</p><p>• Os principais papéis no processo de Arquitetura de</p><p>Software são:</p><p>o Analista de requisitos</p><p>▪ Identificar requisitos funcionais e não-funcionais</p><p>o Arquiteto</p><p>▪ Criar e definir arquitetura;</p><p>▪ Identificar outros requisitos não-funcionais;</p><p>▪ Acompanhar desenvolvimento;</p><p>o Projetista (designer) e/ou desenvolvedor.</p><p>▪ Implementar os componentes e módulos propostos de acordo com a tecnologia escolhida.</p><p>Elementos Arquiteturais</p><p>• Os elementos arquiteturais definem a formação e o entendimento</p><p>do software. Estes elementos definem como o software será</p><p>particionado em pedaços menores e podem ser divididos em</p><p>elementos estáticos e elementos dinâmicos.</p><p>Elementos Arquiteturais</p><p>Elementos Estáticos</p><p>• Definem as partes do sistema e qual sua organização.</p><p>• Reflete o sistema durante o design</p><p>omódulos, classes, pacotes, procedimentos</p><p>oentidades e tabelas de bancos de dados, arquivos de dados, ou</p><p>classes de dados</p><p>o computadores em que o sistema vai executar, roteadores, cabos,</p><p>impressoras</p><p>oassociações, composições</p><p>Elementos Arquiteturais</p><p>Elementos Dinâmicos</p><p>• Definem o comportamento do sistema, sendo</p><p>responsável por representar o comportamento do</p><p>sistema durante a execução.</p><p>• Descrevem como o sistema reage a estímulos internos</p><p>e externos</p><p>omódulos, protocolos, ou classes que realizam comportamento</p><p>Decisões arquiteturais</p><p>• Uma arquitetura não deve ter suas estruturas definidas</p><p>aleatoriamente, uma vez que são elas que permitem o sucesso</p><p>relativo aos objetivos do sistema.</p><p>• O arquiteto deve decidir entre as alternativas, particionando o sistema</p><p>em elementos e relações que possibilitarão o atendimento aos atributos</p><p>de qualidade.</p><p>Decisões arquiteturais</p><p>Rastreabilidade</p><p>• É o processo ou capacidade de ligar requisitos a estruturas</p><p>arquiteturais.</p><p>• Objetivos</p><p>oFacilitar o entendimento através da navegação nos dois sentidos</p><p>oFacilitar a manutenção, pois possibilita descobrir qual elemento</p><p>arquitetural é responsável por não atender a um requisito (e vice-versa)</p><p>Decisões arquiteturais</p><p>Evolução</p><p>• Decisões arquiteturais também descrevem princípios que</p><p>conduzirão a evolução do software, ou seja, regras que serão</p><p>seguidas ao longo do desenvolvimento do sistema</p><p>Recomendações</p><p>Processo da Arquitetura de Software</p><p>1. Grupo reduzido de arquitetos, com um líder bem definido.</p><p>2. O arquiteto deve conhecer os requisitos técnicos do sistema e</p><p>uma lista de prioridades com as propriedades qualitativas que a</p><p>arquitetura deve satisfazer.</p><p>3. A arquitetura deve estar bem documentada, usando notação</p><p>bem definida entre as partes.</p><p>Recomendações</p><p>Processo da Arquitetura de Software</p><p>4. A arquitetura deve ser inspecionada e ativamente revisada pelos</p><p>usuários do sistema.</p><p>5. A arquitetura deve ser analisada para que dela se extraiam</p><p>medições quantitativas e formalmente revista quanto aos aspectos</p><p>qualitativos.</p><p>6. A arquitetura deve conduzir naturalmente à implementação, através</p><p>da criação de um esqueleto de sistema, onde as comunicações (entre</p><p>módulos) devem ser minimamente funcionais.</p><p>7. A arquitetura deve ser conseqüência da escolha de conjunto</p><p>pequeno e específico de áreas de contenção de recursos.</p><p>Importância da</p><p>Arquitetura de Software</p><p>• Comunicação entre os Stakeholders</p><p>• Antecipação das decisões de projeto</p><p>• Reusabilidade</p><p>Exemplo simples sobre Arquitetura de</p><p>Software</p><p>A solução utilizará</p><p>Container ou não?</p><p>Questões comuns sobre</p><p>Arquitetura de Software</p><p>• Se for Windows, como será distribuída, via setup nos clients,</p><p>utilizando distribuição via GPO no domínio ou como smart</p><p>clients?</p><p>• Como serão as futuras atualizações da solução?</p><p>• Como será feito o controle da CAS (Code Access Security), novo</p><p>recurso de segurança no. NET?</p><p>• A solução Windows será usada externamente?</p><p>oSe sim, como será a conexão remota com banco de dados?</p><p>Questões comuns sobre</p><p>Arquitetura de Software</p><p>• Como será o tratamento de sessão?</p><p>• Todas estas questões são importantes, pois suas respectivas</p><p>respostas serão definições para a construção de uma boa</p><p>solução.</p><p>• A tarefa de fornecer respostas para estas questões deve ser</p><p>realizada por um profissional específico com características</p><p>técnicas que o capacite a fazê-la.</p><p>Arquiteto de Software</p><p>[Braga 2007]</p><p>• É o especialista em soluções técnicas para o desenvolvimento de</p><p>sistemas, o que exige uma visão sistêmica madura e aguçada, e</p><p>deve ficar responsável pelas decisões no nível decisório mais</p><p>alto, que é o de Sistema:</p><p>oanálise e conhecimento de tecnologia atual para compor o espaço de</p><p>soluções possíveis;</p><p>oprojeto de sistema em nível alto de abstração, sem detalhes, baseado em</p><p>requisitos não detalhados;</p><p>o identificação e gerência de riscos associados aos projetos</p><p>Arquiteto de Software</p><p>“A função de arquiteto no desenvolvimento de software</p><p>tem sido atacada. Em projetos de software, o título de</p><p>arquiteto é quase sempre definido de modo ambíguo e</p><p>a contribuição dos arquitetos é difícil de ser</p><p>quantificada.”</p><p>[Joseph Hofstader, 2008]</p><p>Arquiteto de Software</p><p>Quando me apresento nas reuniões, as reações vão de</p><p>"não merecemos tanto" a "não precisamos de um</p><p>arquiteto“ - esta última, ainda que dita de forma</p><p>amigável, reflete a imagem arrogante dos arquitetos e a</p><p>primeira, aquela de que o conhecimento e as</p><p>habilidades de um arquiteto são irrelevantes.</p><p>[Joseph Hofstader, 2008]</p><p>Visões Equivocadas sobre o</p><p>Arquiteto de Software</p><p>• Os arquitetos ficam afastados da realidade de se conseguir</p><p>resultados tangíveis e que as suas responsabilidades devem ser</p><p>delegadas aos engenheiros e construtores totalmente</p><p>comprometidos com o desenvolvimento do produto.</p><p>Arquiteto de Software</p><p>• Mas por que esta imagem do Arquiteto de Software?</p><p>o Talvez o principal motivo esteja no fato de grande parte das pessoas da</p><p>área de software, acreditarem que a melhor pessoa para desempenhar a</p><p>tarefa de arquiteto de software seja um Desenvolvedor Experiência e com</p><p>grande vivência de programação.</p><p>Funções do Arquiteto de Software</p><p>• O papel do arquiteto de TI é resolver um problema definindo um</p><p>sistema que possa ser implementado utilizando a tecnologia.</p><p>[Hofstader]</p><p>• Bons arquitetos definem sistemas aplicando conhecimento</p><p>abstrato e métodos comprovados para um conjunto de</p><p>tecnologias com o objetivo de criar uma solução extensível e de</p><p>fácil manutenção. [Hofstader]</p><p>Arquiteto de Software</p><p>Qual será o melhor perfil de</p><p>profissional para assumir o</p><p>papel de Arquiteto de</p><p>Software?</p><p>Características necessárias para um</p><p>Arquiteto de Software</p><p>• Para resolver um problema, o arquiteto deve ter um bom</p><p>entendimento do domínio</p><p>do problema.</p><p>• Definir um sistema utilizando a tecnologia, implica</p><p>perspicácia técnica do arquiteto.</p><p>• Conhecimento abstrato exige do arquiteto capacidade de</p><p>conceitualizar a solução técnica.</p><p>• Métodos comprovados presumem compreensão dos</p><p>padrões usados para resolver problemas similares.</p><p>Características necessárias para um</p><p>Arquiteto de Software</p><p>Habilidades do Arquiteto de Software</p><p>[RUP, 2007]</p><p>• Sólidos conhecimentos práticos de:</p><p>o técnicas de modelagem de casos de uso</p><p>o requisitos do sistema</p><p>o técnicas de design de software, incluindo as técnicas de análise e design</p><p>orientados a objetos, e a Linguagem</p><p>o Unificada de Modelagem tecnologias com as quais o sistema será</p><p>implementado.</p><p>o conhecer a arquitetura do sistema.</p><p>o conhecer o papel dos testes de sistema.</p><p>o ter conhecimento prático dos princípios de gerenciamento de configuração</p><p>em geral.</p><p>Arquiteto de Software</p><p>• A arquitetura de software é um conceito de fácil compreensão e</p><p>que a maioria dos engenheiros entende de modo intuitivo,</p><p>especialmente quando se tem um pouco de experiência.</p><p>• No entanto, é difícil defini-lo com precisão. Em particular, é difícil</p><p>desenhar uma linha bem definida entre o design e a arquitetura —</p><p>a arquitetura é um aspecto do design que se concentra em alguns</p><p>recursos específicos.</p><p>Arquiteto de Software</p><p>• “Um arquiteto é um papel</p><p>generalista. Um projetista é um</p><p>especialista para um determinado</p><p>domínio (ex: Java EE ou .NET)”.</p><p>[Marcos Mendes]</p><p>Arquiteto de Software</p><p>Mitos Sobre o Arquiteto de Software</p><p>[Mendes, 2006]</p><p>• 1 º. Mito: arquiteto = desenvolvedor sênior evoluído.</p><p>oDiferentemente do senso comum, um arquiteto não é um</p><p>desenvolvedor sênior que evoluiu em sua carreira.</p><p>oUm desenvolvedor é especialista e tático. Um arquiteto de sistemas é</p><p>um generalista em sua essência e primordialmente estratégico</p><p>• •2 º. Mito: o arquiteto trabalha em um ambiente isolado</p><p>da realidade do processo de desenvolvimento.</p><p>o Um arquiteto deve trabalhar em intensa e forte colaboração com a equipe,</p><p>apoiando o time na investigação dos pontos de relevância técnica de um</p><p>projeto. Um arquiteto deve atuar como um coach, realizando a identificação</p><p>dos mecanismos arquiteturais relevantes, motivando o time para a</p><p>investigação e resolução destes mecanismos e apoiando o time do início ao</p><p>fim do projeto</p><p>Mitos Sobre o Arquiteto de Software</p><p>[Mendes, 2006]</p><p>• 1 º. Mito: arquiteto = desenvolvedor sênior evoluído.</p><p>oDiferentemente do senso comum, um arquiteto não é um</p><p>desenvolvedor sênior que evoluiu em sua carreira.</p><p>oUm desenvolvedor é especialista e tático. Um arquiteto de sistemas é</p><p>um generalista em sua essência e primordialmente estratégico</p><p>• •2 º. Mito: o arquiteto trabalha em um ambiente isolado</p><p>da realidade do processo de desenvolvimento.</p><p>o Um arquiteto deve trabalhar em intensa e forte colaboração com a equipe,</p><p>apoiando o time na investigação dos pontos de relevância técnica de um</p><p>projeto. Um arquiteto deve atuar como um coach, realizando a identificação</p><p>dos mecanismos arquiteturais relevantes, motivando o time para a</p><p>investigação e resolução destes mecanismos e apoiando o time do início ao</p><p>fim do projeto</p><p>Mitos Sobre o Arquiteto de Software</p><p>[Mendes, 2006]</p><p>• 3 º. Mito: para ser um arquiteto basta conhecer as</p><p>técnicas de arquitetura de software.</p><p>oUm arquiteto de sistemas deve conhecer também outras disciplinas</p><p>(ex: Gerência de Projetos) ou domínios</p><p>o (Hardware, Dados ou Segurança), além da pura implementação J2EE</p><p>ou. NET</p><p>Mitos Sobre o Arquiteto de Software</p><p>[Mendes, 2006]</p><p>• 4 º. Mito: um analista de sistemas ou um programador mais</p><p>experiente pode fazer o mesmo trabalho que um arquiteto de</p><p>software faz.</p><p>oA tarefa do analista de sistemas é fazer o levantamento de informações e</p><p>modelar as regras de negócio.</p><p>oA tarefa do programador é implementar as regras de negócio modeladas.</p><p>oSe qualquer um dos dois, analista ou programador, ficar encarregado de</p><p>definir as questões que seriam tarefa do arquiteto de software uma de</p><p>duas coisas vão ocorrer:</p><p>▪ Ou por falta de especialização técnica as questões não serão bem definidas e</p><p>haverá perda de produtividade no desenvolvimento do software.</p><p>▪ Um dos dois, analista ou programador, tem realmente o conhecimento técnico para</p><p>definir estas questões. Neste caso, estão superqualificados para a função.</p><p>Slide 1: Arquitetura de Software</p><p>Slide 2: Roteiro</p><p>Slide 3: Um pouco de História (Evolução do Custo do Software)</p><p>Slide 4: Um pouco de História (Evolução do Custo do Software)</p><p>Slide 5: Um pouco de História (Evolução do Custo do Software)</p><p>Slide 6: Um pouco de História (Evolução do Custo do Software)</p><p>Slide 7: Um pouco de História (Evolução do Custo do Software)</p><p>Slide 8: Um pouco de História (Evolução da Complexidade e Tamanho)</p><p>Slide 9: Um pouco de História (Evolução da Complexidade e Tamanho)</p><p>Slide 10: Um pouco de História (Evolução da Ambiente de Desenvolvimento)</p><p>Slide 11: Um pouco de História (Evolução da Ambiente de Desenvolvimento)</p><p>Slide 12: Um pouco de História (Evolução da utilização de Software)</p><p>Slide 13: Leis de Lehman</p><p>Slide 14: Leis de Lehman</p><p>Slide 15: Leis de Lehman</p><p>Slide 16: Manutenção de Softwares</p><p>Slide 17: Reflexão</p><p>Slide 18: Software para Locadora de Veículos</p><p>Slide 19: Software para Locadora de Veículos</p><p>Slide 20: Software para Locadora de Veículos</p><p>Slide 21: Software para Locadora de Veículos</p><p>Slide 22: Software para Locadora de Veículos</p><p>Slide 23: Design de Software</p><p>Slide 24: Design de Software​</p><p>Slide 25: Design de Software</p><p>Slide 26: Objetivo de Design</p><p>Slide 27: Níveis do Design de Software</p><p>Slide 28: Software para Locadora de Veículos</p><p>Slide 29: E a Localiza?</p><p>Slide 30: Arquitetura de Software</p><p>Slide 31: Arquitetura de Software</p><p>Slide 32: Arquitetura de Software Perry e Wolf [92]</p><p>Slide 33: Arquitetura de Software Perry e Wolf [92]</p><p>Slide 34: Arquitetura de Software Perry e Wolf [92]</p><p>Slide 35: Arquitetura de Software Garlan e Shaw [93]</p><p>Slide 36: Arquitetura de Software Garlan e Shaw [93]</p><p>Slide 37: Arquitetura de Software Bass et al [2003]</p><p>Slide 38: Arquitetura de Software Bass et al [2003]</p><p>Slide 39: Arquitetura de Software Bass et al [2003]</p><p>Slide 40: Arquitetura de Software Bass et al [2003]</p><p>Slide 41: Arquitetura de Software Padrão ISO/IEEE 1471-2000</p><p>Slide 42: Objetivos da Arquitetura de Software</p><p>Slide 43: O Processo de Arquitetura de Software</p><p>Slide 44: O Processo de Arquitetura de Software</p><p>Slide 45: O Processo de Arquitetura de Software</p><p>Slide 46: Elementos Arquiteturais</p><p>Slide 47: Elementos Arquiteturais Elementos Estáticos</p><p>Slide 48: Elementos Arquiteturais Elementos Dinâmicos</p><p>Slide 49: Decisões arquiteturais</p><p>Slide 50: Decisões arquiteturais Rastreabilidade</p><p>Slide 51: Decisões arquiteturais Evolução</p><p>Slide 52: Recomendações Processo da Arquitetura de Software</p><p>Slide 53: Recomendações Processo da Arquitetura de Software</p><p>Slide 54: Importância da Arquitetura de Software</p><p>Slide 55: Exemplo simples sobre Arquitetura de Software</p><p>Slide 56: Questões comuns sobre Arquitetura de Software</p><p>Slide 57: Questões comuns sobre Arquitetura de Software</p><p>Slide 58: Arquiteto de Software [Braga 2007]</p><p>Slide 59: Arquiteto de Software</p><p>Slide 60: Arquiteto de Software</p><p>Slide 61: Visões Equivocadas sobre o  Arquiteto de Software</p><p>Slide 62: Arquiteto de Software</p><p>Slide 63: Funções do Arquiteto de Software</p><p>Slide 64: Arquiteto de Software</p><p>Slide 65: Características necessárias para um Arquiteto de Software</p><p>Slide 66: Características necessárias para um Arquiteto de Software</p><p>Slide 67: Habilidades do Arquiteto de Software [RUP, 2007]</p><p>Slide 68: Arquiteto de Software</p><p>Slide 69: Arquiteto de Software</p><p>Slide 70: Arquiteto de Software</p><p>Slide 71: Mitos Sobre o Arquiteto de Software [Mendes, 2006]</p><p>Slide 72: Mitos Sobre o Arquiteto de Software [Mendes, 2006]</p><p>Slide 73: Mitos Sobre o Arquiteto de Software [Mendes, 2006]</p><p>Slide 74: Mitos Sobre o Arquiteto de Software [Mendes, 2006]</p><p>Slide 75</p>