Introdução à engenharia de software: aprenda o ciclo de desenvolvimento de software para melhorar a programação

1. Vídeo de introdução: Olá a todos, todos, e bem-vindos ao compartilhamento de habilidades e a este curso de software. Neste curso, vamos discutir principalmente o ciclo de desenvolvimento de software. Então ciclo de desenvolvimento de software é realmente apenas um conjunto de diferentes passos que você pode tomar para projetar um software melhor. Se você estiver projetando, por exemplo , uma pequena calculadora, você não precisa de muita prática prévia e descobrir os detalhes. É uma aplicação pequena. Pode ser, sabe, talvez 100 linhas de código. Talvez seja maior e seja, você sabe, 1000 linhas de código ou até 10.000 linhas de código. Esses projetos não exigem muito planejamento para acertar, porque uma vez que você projetou os 10.000 você pode ter tudo em sua mente. Você pode voltar e retrabalhar, melhorar as coisas, e não será muito difícil. O que começa a ficar problemático é quando você entra em maior do que isso. Se você tem 100.000 linhas de código, de repente há muitas coisas interagindo umas com as outras. Bugs começam a entrar em jogo que você não esperava, e esses bugs começam a ser realmente, muito complexos em vez de um bug que apenas entra em contato com outro lugar. Digamos que em um aplicativo menor você tem um bug que tipo de propagação como este, é fácil de rastrear. Você sabe, você o inseto começa aqui. Olhe para este pedaço de código. Você olha para este pedaço de código, você conserta o bug quando você obtém as peças maiores. Programas maiores de repente têm bugs que se parecem com isso, onde tudo está falando um com o outro. E se você não tem plano e nenhum diagrama, um bug pode parecer que está aparecendo em 100 lugares diferentes, e você precisa ser capaz de descobrir como encontrar coisas assim. Você também precisa descobrir como projetá-lo para que você possa estender mais tarde. Se você quiser fazer seu projeto maior, você precisa de um banco para que ele esteja em um estado onde você pode adicionar a ele facilmente. E é isso que tudo isso vai detalhar. Então vamos começar, que está passando pelo ciclo de desenvolvimento de software. Então vamos falar sobre requisitos e especificações. Este passo é realmente apenas descobrir o que estamos tentando construir, e então como vamos construí-lo. Então vamos para a arquitetura, que é uma espécie de visão muito, muito grande para baixo. Quais são os padrões que vão usar? Quais são as diferentes maneiras realmente conectar as diferentes partes? Como podemos separá-lo para que um monte de gente possa trabalhar nisso? Iam ver o design do software. Uma vez que nos separamos em partes, precisamos descobrir como cada uma dessas partes será construída. É aí que você começa a desenhar as coisas. Você começa a olhar para que loops? Que bibliotecas. Quais as diferentes formas de armazenar dados que você precisa para cada uma dessas partes. Então vamos para a implementação. Foi quando você deu o dedo do pé. Desenvolvedores e desenvolvedores começam a codificá-lo. Então nós estamos olhando para algo como isso onde nós temos um grande problema e eles estavam quebrando em, digamos, um monte de caixas desse tipo. Então quebramos essas caixas ainda mais. E agora começamos a colocar desenvolvedores em cada uma dessas caixas para começar a construí-la . Então olhamos para a implantação. Assim que tivermos tudo isso juntos, como fazemos uma unidade grande coesa e como pegamos essa unidade coesa e a levamos ao mundo real para construir um aplicativo para iPhone? Como entramos na loja? Se estamos construindo um desktop, como obtê-lo para que as pessoas possam comprá-lo? Então a implantação é importante e, finalmente, testes e esses dois tipo de ir e voltar? O teste geralmente é feito antes da implantação, mas muitas vezes vamos implantar em como o mundo de hoje vai implantar um produto mínimo viável ou algo que é rápido vai receber feedback, vai encontrar bugs e erros, e então vamos corrigi-los depois e manter esse tipo de loop de teste, implantação, teste ou realmente ser uma espécie de teste e, em seguida, voltar para o topo todo o caminho de volta para o topo. E você meio que vai nesse ciclo de realmente remodelar e atualizar continuamente e manter seu software. Então, neste curso, isso é o que vamos aprender. Estamos aprendendo todas essas etapas sobre como criar um software melhor, como organizar seu software e, em geral, como garantir que quando você constrói algo grande, ele acabe funcionando. No final 2. 1-1 Por que usar modelos: vamos rever a importância de realmente o curso em geral. Por que estamos usando modelos de software e engenharia de software? Por que não codificamos a coisa? Por que não entramos e fazemos o projeto? Bem, isso se torna mais aparente sempre que pensamos em outro projeto, algo que está no mundo físico. Vamos falar sobre construir uma ponte. Imagine se você estiver construindo uma ponte e você começar de cada lado. Então você tem, tipo, esse rio e você começa a construir no lado esquerdo e no lado direito e você se junta no meio. Muitas pontes são criadas assim porque você pode criá-la duas vezes mais rápido em vez de ter que construir a partir da direita e atravessar todo o caminho. Você pode realmente começar em ambos os lados com duas equipes de construção e apenas se encontrar no meio. No Japão, a bala treina as grandes e velhas ferrovias. Na verdade, geralmente começaram em oito ou nove locais diferentes, e todos eles apenas conectando o fim. Imagine, entanto, se esta ponte aqui, se ela se conectou no meio e era como 3 metros de distância um do outro, Então, em vez desta ponte reta perfeita agora temos parte das pistas no direita e parte das pistas à esquerda que na verdade apenas ir direto para o oceano. Isso seria uma catástrofe. Essa ponte seria inútil. Não seríamos capazes de trabalhar com ele. E engenharia de software, podemos considerar esses dois lados. Ah, Bug. Ah, um inseto bem grande. Mas só um inseto. E da esquerda e da direita, talvez do topo. Talvez como o muito, muito para trás, pode parecer que a ponte está funcionando. No entanto, a estrutura não é sólida. Não no Lee. Poderia cair por causa disso? Mas também, pode haver um problema em que as pessoas simplesmente dirigem para o oceano. É uma catástrofe para a construtora, porque agora, porque agora, não só eles têm que pagar para construir a ponte pela primeira vez, eles também têm que pagar para desconstruí-la e depois reconstruir a ponte corretamente. E isso custou muito dinheiro. E talvez a construtora falhe. Tem que ser abandonado. E agora temos esta ponte sentada aqui que vai apodrecer. E nós realmente não temos uma solução para o problema. Estamos tentando consertar. Então isso é que tipo de é a importância de todo esse planejamento. Perderam um único plano. Aceito. Custa milhões. Muita gente acha que isso não pode acontecer. E engenharia de software, vou consertá-lo mais tarde. É tudo código. Enfraquecer, apagar e reescrever. No entanto, sempre que você entra em milhões de linhas de código, isso se torna um problema. A Amazon, por exemplo, eu acho, tem mais de 10 milhões de linhas de código ou ainda mais o mesmo com o Facebook e todas essas grandes entidades. Eles têm todo esse código. Imagine se você de alguma forma criou um bug lá que se representa em, por exemplo, no Facebook na página de amigos. Mas na verdade é algo a ver com o feed da linha do tempo. Imagine como isso seria difícil de depurar. Isto é algo chamado dívida técnica. Esta é a minha definição. Ah, pobre difícil de entender implementação hacky, que terá que ser reembolsado com juros mais tarde. Então isso realmente se resume a cortar cantos no início, não realmente planejar algo fora e apenas saltar para dentro. Pode parecer que funciona agora que você fez um pequeno teste rápido. Não há insetos, então, você sabe, economize a ou duas horas de planejamento, e agora você pode passar para a próxima coisa. No entanto, isso pode custar-lhe mais de 20 horas depois. Imagine que é apenas uma pequena linha em um arquivo e você colocá-lo lá e você não documenta e não há planos de dedo do pé. Porque é que o puseste lá dentro. Também não há comentários para explicar por que você colocou lá agora, 68 meses depois. 68 meses. Talvez três anos depois isto, na verdade, esta linha que puseste aí cria uma escuta. Outro programador entra para tentar consertá-lo. Ele não só tem que encontrar a linha original que você colocou lá, mas talvez não coloque nenhum tipo de bug nesse arquivo. Talvez ele realmente crie um bug em uma parte completamente diferente do servidor. Então ele tem que passar por todo o processo de rastreamento para voltar a essa linha de código. E então, uma vez que ele vê, sim, para entender o que era suposto para dificar olhar para cima a maneira correta de fazê-lo, documentar a maneira correta de fazê-lo e, em seguida, corrigir a linha. Isso é muito mais trabalho do que apenas você fazendo isso no início, onde você já entende como essa coisa está sendo construída e você apenas coloca a linha de código adequada lá. Assim, com este exemplo, você pode ver rapidamente como os custos podem subir e disparar quanto mais tempo eles esperam, porque talvez aqui haja apenas 10 arquivos. E daqui a quatro meses há potencialmente até 400 arquivos. E quando voltarmos para o desenvolvimento, talvez tenhamos algo como 1000 arquivos diferentes para verificar. E esta pequena linha que um casaco se torna cada vez mais difícil e mais difícil e mais difícil de encontrar, especialmente se houver práticas de programação pobres em outros lugares na produção. E esse tipo de coisa pode realmente levar a isso. Este número 80 dos 20% dos projetos falhando. Isso é uma estatística real. Eu esqueço de que estudo veio, mas era semi recente e imagino todas essas empresas criando software que pode custar milhões de dólares. Isso significa que 20% desses $1.000.000 Softwares são apenas eles falham. A empresa acabou de desperdiçar o seu dinheiro e não tem de recuperar nada. Não há nenhum ano, nenhum retorno sobre o investimento em tudo. Isso é muito, muito ruim para a empresa. Este custo é realmente calculado em um estudo recente para US $85 bilhões por ano. E isso geralmente se resume a isso. É um típico desenvolvedor, Spence. 13,5 horas sobre esta dívida técnica e, em seguida, 3,8 horas para corrigir ou depurar código inválido adicional ou até mesmo adicionar mais código inválido. Então você sabe que você está sentado aqui e você está gastando todo esse tempo e dinheiro em corrigir erros antigos, e você pode realmente estar implementando erros MAWR mais tarde. E este é um grande custo. Isto é para um desenvolvedor que paga 50 dólares por hora. Poderia ser, você sabe, isso é mais de cerca de US $700 cada semana para cada desenvolvedor que você está desperdiçando porque as pessoas cortam cantos no início. Então, a engenharia de software em geral nos permite nos unir, criar um plano central e evitar muitos desses bugs olhando para este código, este é apenas um exemplo muito rápido. Então você pode ver Apenas uma espécie de algo físico para olhar é imaginar. Você se deparou com essa linha de código e queria descobrir o que ele faz agora. Normalmente, isso não é. Sabe, isso não é muito difícil, mas isso poderia ser muito , muito difícil se alguém tivesse ido ao fundo, sabe, Revestindo essa coisa. Mas agora temos que olhar para isto. Temos que entender o que isso está fazendo. E então nós podemos até ter que, , você sabe, pegar um pedaço de papel rápido e ser como, OK, verdade. Está bem. Dados falsos. Oh, ok. Essa linha de código é completamente equivalente a todo esse bloco, e isso pode ser nos descartar. Talvez desperdice 10 minutos do nosso tempo para consertar, mesmo sendo apenas 10 minutos. Se estamos pagando 50 dólares por hora, são alguns dólares de tempo da empresa. E não só isso, mas digamos que todo o arquivo ou toda vez que o programador queria fazer isso aqui, há apenas verificar se a e B são ambas notas Knoll. Ao mesmo tempo, ele acrescentou isso toda vez que um programador encontra lá vai perder esse tempo, e isso só aumenta a dívida técnica uma e outra vez e outra. Então, no final, o que estou tentando dizer é que a parte importante deste curso é aprender que o design é importante. Se você vai criar algo que é, você sabe, maior do que apenas uma pequena adição ou um pequeno jogo ou algo assim, então projetá-lo para que ele pudesse ser expandido, ele poderia ser colaborado em, e ele não cria essas situações realmente ruins mais tarde é importante. E isso é que nós vamos estar indo sobre este curso é como fazer. Tudo isso é como criar um plano e como se juntar a uma equipe e entender o que eles estão falando. 3. Ciclo de desenvolvimento de software de 1 de 2: Então vamos saltar para o tipo de ciclo de desenvolvimento de software, a maneira como nós projetamos software com software. Há um monte de maneiras diferentes que você pode fazer isso e esses geralmente chamados de modelos, e é assim que você realmente implementa esse tipo de cinco etapas. No entanto, esses cinco passos geralmente são cruciais para obter um pedaço de software até padrões que são, você sabe, muito confiáveis. Com isso, você também vai notar que estes podem ser aplicados a qualquer prática de engenharia como na última palestra. Quando falo sobre a construção de uma ponte, isso poderia ser usado para isso também. Passaríamos por cima dos requisitos, design e implementação, verificação e manutenção, tudo com uma ponte. Então, se quisermos pensar assim enquanto passamos por isso, pode fazê-lo ficar um pouco melhor. A primeira coisa que queremos falar é que queremos falar sobre algo chamado requisitos, modo que os requisitos são bastante simples. Os requisitos são o que estamos construindo? Então os requisitos são o quê? O que vamos construir? Queremos ser capazes de chegar a um ponto em que ninguém seja capaz de contestar o que estamos construindo. O que quero dizer com isso é que não queremos um grupo de oito pessoas construindo tudo isso com uma idéia diferente do que o produto final vai ser. Nós não queremos que eles pensem que, você sabe, talvez uma pessoa pense que ele vai usar oito servidores. Alguém acha que vai ser apenas um servidor local. Pensa-se que onde vai ser um negócio, como se fosse usado principalmente por empresários. Enquanto alguém pensa que vai ser usado principalmente pelos consumidores. Isso seria um grande problema se você está tentando fazer com que um monte de pessoas trabalhem juntos em um projeto que todos construiriam em uma direção diferente e ele iria desmoronar . Então, com os requisitos, o que estamos tentando conseguir é o que estamos construindo? E há um monte de pequenos passos diferentes em cada um desses, e é isso que tipo de curso inteiro vai ser sobre saltar para o Então isso é apenas uma visão de cima para baixo e eu vou fazer um mergulho profundo, um pouco mais tarde. Então, de qualquer forma, requisitos é o 1º 2º é o design. O design é o Como é que vamos construí-lo? O que vamos usar? Que tipo de tecnologias vamos montar? Como com o servidor vai ser configurado? Como é que a frente vai ser montada? O front-end deve fazer isto ou aquilo? É aí que o design entra e o design é muito importante. Muitas pessoas pulam este passo. Ah, muita gente vai fazer os requisitos, embora eles vão fazer requisitos, mas então eles não vão realmente descer para o design. Eles são apenas uma espécie de salto direto para a implementação. Então você sabe, eles vão ser como, OK, nós meio que temos uma boa idéia do que vamos construir. Vamos pular na implementação. E isso pode ser perigoso porque, novamente, ainda existem algumas variáveis aqui, e ainda há algumas coisas que queremos garantir que funcionem antes de implementá-las. Porque, por exemplo, digamos que você construiu uma obra-prima gigante de oito servidores ou pelo menos você acha que é uma obra-prima. E então quando você clica, você sabe o botão play, você finalmente começa a funcionar. Você percebe, Oh, isso não funciona com oito servidores. Ele só funciona com o serviço. Só funciona com este tipo de tecnologia. Vou ter que reiniciar e começar desde o início. Esse é o tipo de coisas que você quer trabalhar para fora na parte de design. A parte como Depois de ir projetar, saltamos para a implementação e todos sabem o que é a implementação. Implementação é você apenas construir a coisa. Então você fez todo o planejamento. Todos estão na mesma página. Agora você vai dividi-lo em Talvez você tenha equipes. Talvez seja só um grupo de três pessoas. Talvez seja só você mesmo, e você só vai entrar em certas, tipo, tarefas e marcos. Mas a parte de implementação é a parte de construção que você vai construir o produto, você vai criar o que você se propôs a criar, e então o próximo passo é a verificação. Então, com a verificação, o que estamos fazendo é algo chamado teste. Por isso, estamos a tentar descobrir uma questão crucial aqui. O que construímos é o que queríamos construir? Isso é muitas vezes ah, algumas coisas diferentes. Então, por exemplo, é o que construímos o que queríamos construir é o que construímos. O que nosso cliente queria que construíssemos é o que construímos funcionando corretamente. É a entrada que entra? E é, você sabe, criar a saída adequada. E é por isso que o teste vem em uma peça, e geralmente com testes, você precisa conhecer os requisitos. Você precisa saber o que era suposto fazer e, em seguida, com teste Utkan teste contra isso não faz o que era suposto para dio. Portanto, este é um passo muito importante. E este é outro que muitas vezes é meio que para obter. Se o tempo crunch as pessoas gostam, Oh , não, não se preocupe com testes vai fazer alguns testes rápidos e então vamos seguir em frente. E isso pode ser um grande problema porque então você tem aqueles bugs gigantes em seu programa. Talvez eles não se manifestem por alguns anos, e então isso leva a uma grande violação de segurança de dados. Ou talvez seja algo muito pequeno ao longo do tempo. Talvez todos os dados que vão para o banco de dados estejam desligados por um, e eles meio que distorcem seus dados, e então custarão muito mais tarde na fase de manutenção, que é esta fase aqui para acabar consertando-o. Portanto, a verificação e o teste são importantes. Vamos cobrir algumas técnicas sobre isso e algumas das maneiras que você deve estar testando. E então, finalmente, o que temos é que temos manutenção. E este é o tipo de ciclo final onde você vai estar corrigindo bugs. Você também vai ser uma espécie de talvez até mesmo fazer mais testes pode estar implementando algumas outras coisas, talvez redesenhando coisas. As coisas de manutenção são uma espécie de como este ciclo de volta muitas vezes. Se você estiver, por exemplo, desenvolvendo um recurso adicional, você realmente percorreria todo o caminho de volta para os requisitos e, em seguida, começar esse processo . Mas o ciclo de manutenção é normalmente apenas corrigindo bugs, certificando-se de que, como pequenos ajustes para torná-lo mais em linha com os requisitos e mantê-lo em execução para me fazer não fazer atualizações de servidor e atualizar esta tecnologia em que tecnologia. Portanto, a manutenção é importante e a manutenção pode ser muito difícil se você não fizer todas essas etapas. Então, pode haver uma tonelada de bugs se você não tiver tudo isso, e especialmente se não houver documentação nisso. Então você não escreveu nada? Você não tinha esse plano escrito. Então pode ser muito difícil porque você não pode realmente trazer outros programadores. Levarão seis meses para aprender o código baseado, etc, etc. Mas de qualquer forma, esta é a visão de cima para baixo do ciclo típico de desenvolvimento de software. Agora, ao longo do resto, é claro, vamos começar a quebrar isso um pouco a pouco e, em seguida, tipo de mergulho profundo em cada um desses e, em seguida, olhar para coisas legais como modelos que são todos, como, como você combina esses diferentes passos da melhor maneira de fazer isso, sabe? Você faz isso como um V onde você meio que coloca alguns desses em cada lado dele? Você faz isso? Há essas coisas chamadas Scrum na cachoeira que significam que vão passar por cima de tudo isso. Mas o ciclo de desenvolvimento de software é muito bom saber. E você vai estar vendo isso muito 4. Exemplo de ciclo de software: Vamos dar um pequeno exemplo para ajudar a enviar isso um pouco mais antes de começarmos a mergulhar fundo em cada uma dessas áreas. Vamos repassar um exemplo aqui. O exemplo vai ser simples. Vai ser como construir um formulário. Ou principalmente o que estamos fazendo é que temos esse objetivo. Queremos construir um formulário, ele vai ter um endereço de e-mail, e vai ter um lugar para comentários e pronto. Só queremos rever o que aconteceu. Nós fazemos isso. O design de requisitos, implementação, etc. Em. Este é um exemplo muito básico. Você poderia realmente obter realmente em profundidade e realmente vir acima com um grande documento para algo tão pequeno. Mas eu só quero rever algumas coisas básicas. Então você entende o quê? Como cada uma dessas áreas funciona um pouco mais. Portanto, a primeira área que queremos analisar são os requisitos. Então, o que queremos que este formulário difunda? Queríamos coletar e-mail, endereço e mensagem. Isso é o que queremos que o formulário original faça. Vai recolher um endereço de e-mail e uma mensagem, depois pecou também, também, e guardar numa base de dados. Então ele envia essa informação através da Internet para o nosso banco de dados. E, em seguida, queremos evitar que o usuário de entrada incorreta, isso significa no endereço de e-mail, colocando todos esses símbolos aleatórios e não realmente criar um endereço de e-mail na seção de comentários . Você sabe, tentar inserir código ou fazer um ataque de injeção SQL ou algo assim impediria esse tipo de coisas. Então, três requisitos básicos aqui, então vamos para o nosso projeto. O que fazer Como queremos projetar isso agora, com o design, você pode criar um documento ou você pode realmente tipo de puxá-lo para fora. Muitas vezes você precisa de um front-end e volta no design. Então, sabe, talvez tenhamos apenas uma caixa rápida. Aqui temos o lugar de e-mail e, em seguida, o lugar de comentário maior, e, em seguida, quando nós desenhá-lo para fora, nós iríamos , Oh, realmente precisamos de um botão para enviar isso. Então talvez queiramos colocar isso em nossas necessidades. Precisa de botão. Exactamente. Então você sabe, só algo no dedo do pé. Você sempre pode ir e voltar entre os requisitos do design, dependendo do uso do modelo e falaremos sobre isso mais tarde. Você sempre pode ir e voltar entre os requisitos do design, Mas com o nosso design, queremos usar HTML e CSS para construir as estruturas do formulário. Então queremos construir o tipo de que realmente olhamos como HTML e CSS. Em seguida, queremos usar JavaScript para verificação da entrada. E então nós queremos usar Jake cansado no meu SQL para entrar em contato com o back-end e Jake onde você não ouviu falar. É apenas JavaScript, mas meio que ajustado. Então você pode enviar tipo de solicitações de postagem para um banco de dados, e então meu SQL é apenas um banco de dados. A próxima parte é a implementação, e isso é muito, muito fácil. Isto é apenas código e documento. O trabalho será fácil. Neste sentido, este será realmente o lugar onde a maior parte do tempo é gasto. Depois de fazermos essas duas coisas é apenas uma espécie de trabalhar tudo para fora, configurar um servidor, configurar o front-end e o JavaScript etc. Agora em verificação Muitas vezes a verificação, o teste é apenas uma espécie de extensão dos requisitos. Fazemos perguntas sobre os requisitos, então colete endereços de e-mail e mensagem. Um formulário coleta informações. Então nós criaríamos um teste para testar a coleta de informações, enviar e armazenar em um banco de dados. O formulário envia essa informação para um banco de dados? Poderíamos fazer testes nisso. Nós podemos ver, você sabe, colocá-lo no front-end e então ir verificar nosso banco de dados e ter certeza que ele está fazendo isso no back-end. Talvez encurralar casos tentando inserir 100 navegadores diferentes ao mesmo tempo, ou tentar inseri-los todos em sequência, talvez meio segundo um do outro. Talvez haja uma fila que fica sobrecarregada ou algo assim, então esses tipos de testes ajudarão a garantir que você não perca informações e, finalmente, impedir que o usuário bata. Mas tente fazer um ataque de injeção SQL em si mesmo. Tente colocar caracteres realmente aleatórios por toda parte. Isso não seria realmente uma mensagem, talvez até mesmo prevenção de spam. Talvez queiramos construir uma coisa de prevenção de spam aqui, e precisamos colocar isso em um requisito para projetar. Mas nós testamos isso também, e finalmente temos a manutenção, que é apenas criar um plano de ciclo de vida e corrigir quaisquer bugs. jogo do ciclo de vida pode ser simples como verificar a cada seis meses para se certificar de que toda a tecnologia usa mais atualizado e o mesmo com o banco de dados atualizado a cada seis meses. Verifique qualquer bug, talvez atualize isso a cada seis meses. Ou talvez você tenha uma agenda semanal de como os insetos entram em sua empresa ou o que quer que seja. Mas uma manutenção é apenas uma espécie de elaboração de um plano para garantir que possamos ajustá-lo para atender aos requisitos para atender ao que queríamos fazer e também para garantir que não seja vulnerável. E aqui temos apenas um exemplo muito, muito simples de como você pode passar por essas etapas, como você pode classificar apenas construindo uma forma simples. Agora, nas próximas palestras, vamos começar a saltar para a parte realmente em profundidade onde você pode realmente tipo de usar algumas das ferramentas que falamos para construir para fazer isso. Mas para algo muito, muito maior em escala 5. Definição de requisitos: vamos começar nosso aprofundamento nos requisitos. O primeiro que vou rever é a definição de requisitos, algo que estamos todos na mesma página. Então todos nós entendemos o que eu quero dizer com requisitos. Portanto, os requisitos são uma maneira de descobrir as especificações exatas do que o software deve fazer. Você pode pensar em requisitos como uma definição. Você está definindo o que o software deve fazer. É como se você estivesse procurando em um livro e você fosse capaz de ler exatamente o que o software deve difundir. Isso é importante. Não estamos tentando descobrir como deve ser criado. Só estamos tentando descobrir o que deve fazer no final. Se o usuário interage com ele aqui ou para, você sabe, e o usuário interage com ele lá, o que vai acontecer? O que queremos que aconteça? Qual é o propósito deste sistema? E é por isso que é um processo para descobrir os objetivos de um sistema. Então, no final, os requisitos estão apenas tentando descobrir os objetivos do sistema. O que queríamos fazer isso captura o que e não o como isso é importante é que estamos apenas tentando descobrir o que não como estamos tentando criá-lo. O como é para o design. Muitas pessoas podem chegar a um requisito de usará C, S e HTML para construir o front-end. E isso não é um requisito. Isso é três. Como é isso que vamos usar para construir o front-end. E assim, portanto, isso é uma parte do requisito de design. Pode ser. Usa um campo de endereço de e-mail para capturar o endereço de e-mail. Ou queremos capturar o endereço de e-mail e um comentário. Então não vamos dizer como vamos fazer isso. Não estamos tentando definir tecnologia sobre como estamos tentando fazer isso. Só estamos dizendo, o que queremos que o usuário seja capaz de fazer? O que queremos? O objetivo final a ser? E, no geral, os requisitos geralmente criam um documento que estabelece todos esses detalhes. Normalmente há listas de balas ou se ele é oficial, você tem necessidade de dois A ou algo assim. se ele é oficial, você tem se ele é oficial, você tem necessidade de dois A ou algo assim. Mas muitas vezes, se você está apenas trabalhando para empresas médias ou pequenas, será apenas uma espécie de lista das coisas que você quer realizar e os casos de uso que você quer que os usuários acompanhem. Então, vamos cobrir a importância dos requisitos. Por que usamos os requisitos? O que? O que está nos salvando no final? Parece que estamos gastando mais tempo. Poderíamos estar cobrindo bem com toda a engenharia. E isto é importante. Isso é engenharia? Você dio qualquer engenharia você dio você tem este tipo de regra de ouro ea regra de ouro é que gastar tempo estrategicamente adiantado reduz custo e tempo mais tarde. Agora, estes são dados de um estudo que mostrou se você passou um tempo estratégico fora da razão pela qual eu digo que estratégica é não estão apenas falando, você sabe, você sabe, antes de nós projetarmos a coisa apenas conversando para trás e para frente, você sabe, 40 horas nós queremos realmente ser, você sabe, você sabe, trabalho focado aqui, projetando, encontrando possíveis problemas, encontrando todos os possíveis casos de uso, você sabe, criando basicamente o código antes mesmo de tocar no código. É disso que estou falando. Então, passar o tempo estrategicamente adiantado reduz o custo e o tempo mais tarde, e esta é uma espécie de tendência aqui. Não, Lotus, que a tendência é um pouco como esta tendência de perda de tempo. Então, há um ponto em que isso não ajuda você a usar mais tempo adiantado. Então, você sabe, se estamos indo dentro de 50% de todos os tempos, isso não vai fazer muita mudança aqui. Na verdade, não vai reduzir o custo de superação. Você percebe que isso não vai para zero. Isso porque a maioria dos projetos sempre ultrapassa 40%. O orçamento é uma espécie de norma, e muitas vezes ele se eleva nesses grandes números porque as pessoas não planejam adequadamente. Mas isso é apenas dizer do tempo total aqui. Então este é o tempo total. O que estamos falando é se gastarmos 0% do nosso tempo, então não estamos gastando nenhum tempo adiantado. O custo típico é 200%. Se gastarmos cerca de 3% e cerca de 5%, tínhamos 100% e 50%, por isso só fomos 5% de todo o nosso tempo muito, muito pequeno pedaço de tempo, sabe, se ele passou 100 horas, estamos falando de cinco horas adiantadas, apenas a rever esta coisa. Podemos economizar 150% de superação extra. E isso é mais caro em dólares e no tempo. Então é também é ambos de costume porque os dois andam de mãos dadas um com o outro. Se demorar mais, vai custar mais. Você está pagando seus engenheiros, pagando por cuidados de saúde, sua dor por impostos. Você está pagando tudo isso. E quanto mais tempo levar para você começar a ganhar seu dinheiro de volta, mais vai custar. E então, se formos de 10 a 20%, teremos aquela área dourada onde obtemos apenas 40% de superação. E para que saibas, qual é a diferença entre isto? Digamos que gastamos 0% na frente e o produto deve ter demorado 200 horas. Bem, isso é apenas uma matemática simples aqui vai ter uma superação de 200%, que significa que estamos olhando 100 no geral será 400 então um 200% sobre sobre ele vai ser cerca de 600 horas para completar este projeto quando ele deve ter apenas em 200 Isso é um salto gigante gigante bem ali do tempo que deveria ter levado onde se nós apenas colocássemos 5%. Então, nesses 200 nosso projeto, se tivéssemos apenas designado 5% ou 10 horas, então estaríamos em Lee em uma superação de 50%, que significa que nosso total seria de 300 horas. Então, com 10 horas de esforço aqui, nós realmente economizamos 300 horas de problemas de back-end. E isso é como se o poder de tudo isso fosse que passar tempo adiantado ajuda os requisitos. Documento é uma daquelas coisas para passar o tempo na frente e mesmo com o documento de design . Mas ambos são muito importantes. Eles nos colocam na mesma página e nos fazem trabalhar eficientemente. 6. Requisitos vs: Há um par de categorias diferentes sempre que falamos sobre toda a etapa arqueada dos requisitos. E essas categorias definiram diferentes aspectos do sistema que estamos tentando construir nesta palestra. O que estamos falando é de requisitos e especificações, então há uma grande diferença entre os dois e você verá no início que eles parecem bastante semelhantes. Mas sempre que você começa a mergulhar nessas coisas, você entende que há uma importância entre os dois. O versículo sobre o qual vamos falar vai ser os requisitos. Assim, com os requisitos, o que nossos requisitos serão. Um requisito é uma definição não técnica de algo que o usuário exige do sistema . Então o que isso significa é que é colocado em termos leigos. Deve ser entendido por qualquer um. Então nada de jargão. Este tipo de jargão não está falando sobre ciência da computação, sem jargão de programação. Se você está fazendo um formulário médico, você conhece nosso formulário de busca por tratamento. Você pode colocar em jargão no campo médico ou no campo da construção no requisito do usuário , porque nosso público vai ser, você sabe, o campo médico do campo da construção ou o aplicativo Campo de desenvolvimento. Isso é perfeitamente OK. No entanto, nós não queremos colocar em é jargão como meu SQL ou Jason qualquer coisa que isso deve ser capaz de ser lido pelo gerente de construção ou por, você sabe, o gerente de fábrica de automóveis. Ele deve ser capaz de ler isso e entender. Sim, é isso que queremos no nosso sistema. Então, com os requisitos, não queremos nenhum jargão de ciência da computação. Assim, por exemplo, um requisito pode ser a capacidade de enviar um pedido de formulário médico de tratamento. Sabemos o que é um formulário de pedido de tratamento? Não realmente? Não importa para nós. O que sabemos é que falamos com o cliente e eles dizem que querem a capacidade de enviar um pedido de tratamento, formulário médico e com este fraco inquérito sobre isso mais tarde. Mas sabemos que seria uma forma médica, portanto, deveria haver alguma segurança lá. Vai ser algum tipo de formulário de contato do pedido de tratamento, e então esse será o nosso requisito para este passo. E então, como eu disse mais tarde, podemos esclarecer com eles exatamente o que eles significam. Então temos essas especificações, então as especificações são basicamente notas técnicas, notas sobre o que precisa ser feito para atender ao requisito. Então, nesta situação, é uma definição técnica do que é exigido do sistema. Vamos manter isso simples. Não estamos a tentar desenhá-lo aqui. Isso é muito importante. Este é o maior erro que você não estava tentando projetá-lo. O que estamos tentando fazer é apenas, basicamente, embora algumas palavras-chave de nível superior aqui. Portanto, entendemos a importância de certos aspectos da exigência. Assim, nesta situação saindo deste requisito, uma especificação pode ser enviar em A s para 56 dados de formulário criptografados do front-end para o servidor backend. Você vai notar que temos um pouco de jargão lá dentro. Chegamos na frente e voltamos. Temos um S C 2 56 criptografado, mas nada disso está definindo a tecnologia. vamos usar nada disso dizendo que vamos pegá-lo e passá-lo assim através deste meio, como, você sabe, você sabe, uma espécie de explicação muito profunda. Você notará que este é o incorreto. Isto é o que tínhamos colocado no documento de design que vamos usar criptografia, que é uma tecnologia para criptografar dados dentro do JavaScript para enviar A S para 56 criptografados. Jason se formou de novo. É uma forma de se formar. Não precisamos saber exatamente a tecnologia que estamos usando formada a partir de JavaScript. Isso é uma tecnologia para o meu servidor SQL, etc, etc. Há muito jargão nisso. Há muita coisa basicamente definindo como o projeto vai ser construído. Essa fase não é sobre isso. Tudo o que estamos tentando dizer é que precisamos de alguns dados criptografados. Nós preferimos que seja o Secure A es 2 56 E você sabe, hoje em dia é provavelmente nós gostaríamos de usar uma tecnologia diferente, mas isso é apenas para o exemplo. Mas de qualquer forma, queremos usar A S para 56 queremos levá-lo do front-end, onde o usuário pode se conectar ao back-end. Não é necessário mais informação depois disso. Quando chegarmos ao conjunto de design , podemos começar a trazer as tecnologias que vamos usar. Então vamos repassar alguns exemplos aqui. primeiro exemplo é vamos voltar ao mundo real. Vamos falar sobre a criação de um pneu de SUV. E com este pneu SUV, o que vamos estar falando é basicamente apenas um requisito simples e em algumas especificações que podem ir com esse requisito para que possamos ver novamente a diferença entre os dois. Normalmente, sempre que estamos falando fora dessas coisas, vamos dizer requisitos do usuário e férias sistema Sessa. O que isso significa é que é uma espécie de defini-la. Então todos estão na mesma página sempre que estamos falando sobre requisitos estavam falando sobre o que o usuário quer ser capaz de dio. Nunca. Estamos falando das especificações do sistema. Estamos falando sobre como o sistema deve operar basicamente, então algumas das restrições alguns dos requisitos com o próprio sistema. Assim, a exigência do usuário estava dizendo que o pneu deve trabalhar em um carro tipo SUV. Ou talvez o usuário deve ser capaz de colocar o pneu em um carro tipo SUV. Qualquer aviso disso capta o ponto. Temos um usuário. Ele quer ser capaz de pegar este pneu e colocá-lo em um automóvel. É isso. Agora as especificações. O que esse pneu tem a ver? O que isso significa? para pegar um pneu e colocá-lo em um carro tipo SUV. E novamente, você vê, isso é um pouco de jargão, mas tudo bem porque estamos na indústria automobilística. Portanto, podemos usar o jargão da indústria automobilística aqui em cima. Não vamos falar de nada específico até chegarmos a esta parte. Então o que vamos dizer é que o pneu deve ser capaz de suportar até 7500 libras de pressão descendente. O pneu deve caber todos nós pontos padrões para a montagem do pneu deve caber toda a segurança ust. Padrões de segurança e o pneu deve ter chá ou maior qualidade de velocidade. Vocês não precisam saber o que qualquer um de vocês sabe que isso significa, mas o que vocês podem ver é que aqui em cima nós temos o requisito básico. E aqui em baixo nós estamos apenas especificando algumas das coisas que o pneu deve dilatar. Não estamos falando da química exata da borracha que deve ser usada. Não estamos falando da pressão do ar dentro do pneu para adquirir £7500 de pressão de ar . Não estamos falando de design. Tudo o que estamos falando são apenas algumas das restrições, algumas das coisas que precisamos implementar neste pneu. Finalmente, vamos voltar um pouco para o mundo da tecnologia. Então agora temos esse outro requisito. Os usuários devem ser capazes de enviar um vídeo para o site. Temos um grande site. Existem 100 desses requisitos e este é apenas um dos requisitos. Estes devem ser capazes de carregar um vídeo para o site. Então agora só temos algumas especificações aqui em baixo. O que o usuário deve aceitar? H 0.264 mover e arquivos mpg para upload Estas apenas categorias. Não estamos dizendo como eles vão ser, exceto que não estamos dizendo a tecnologia que precisamos usar para aceitá-los. Como é que eles estão? O que devemos ser capazes de aceitar? O que queremos dizer com um vídeo. E então nós estamos especificando que com isso apenas um pouco, e então o upload do carregador deve comprimir o vídeo e salvar três cópias diferentes no servidor novamente. Isso não é algo que o novo usuário realmente precisa saber. Isso é apenas algo que nós, como designers deste site, estamos olhando e dizendo tarde, vamos querer pegar este vídeo e usá-lo de certas maneiras. Devemos comprimir e salvá-lo no servidor novamente. Não estamos mencionando o tipo de servidor. Não estamos mencionando as dimensões dos três vídeos. Só deve ter a habilidade de fazer isso. E, finalmente, um link para o vídeo ou vídeo compactado depende de como queremos que seja. Deve ser enviado por e-mail para o usuário após a conclusão. Novamente, não estamos falando de servidores de e-mail ou como vamos formatar o e-mail ou você sabe como deve ser o link. Como o leitor de vídeo, qualquer uma dessas coisas. Não estamos falando sobre isso. Estamos falando de especificações aqui. O link, depois de terminar, deve ser enviado ao usuário. E, claro, isso pode não ser tudo incluído. Pode haver mais que precisamos de nos sentar e começar a marcar mais um pouco. Isto e depois talvez tenhamos outra exigência. Portanto, precisamos de ainda mais especificações, etcetera, etc. Mas espero que no geral você tenha a idéia do que a diferença entre um requisito e as especificações é exigência lida com o usuário. É muito básico. É em termos leigos, algo que um cliente pode olhar e ir. Sim, o programa definitivamente deve ser capaz de fazer isso ou não, talvez isso não defina exatamente o que queremos. E então as especificações do sistema são como as nossas notas. É como se as notas do desenvolvedor estivessem dizendo, Ok, então o usuário quer que Bill faça isso, e o que ele realmente quer é que ele precise ser capaz de carregar esses tipos de arquivos. Ele precisa ser capaz de fazer isso com as necessidades dos pneus para atender a esses padrões, e é isso que as especificações do sistema se resumem. 7. 2-3 funcional vs não funcional: as outras duas categorias que realmente precisamos discutir quando falamos sobre requisitos são versos não-funcionais, requisitos funcionais. Então, qual é a diferença entre estes dois? Será que os requisitos funcionais são requisitos e especificações pertencentes à função do programa? Essa é a palavra-chave aqui. É a função do programa aqui. Então o que estamos falando é sobre o que o sistema deve pagar? No final, o que o sistema deveria ser capaz de realizar foi construir uma forma. Descemos a lista das coisas que o formulário deve ser capaz de dialogar, deve coletar dados. Ele deve enviar dados que deve proteger contra entrada. Deve fazer isso. Deve fazer isso agora. Não funcionais são os requisitos e especificações sobre quais metas devem ser atendidas. Por exemplo, segurança. Qual deve o formulário agora ser criptografado como ou custo? Como é que o tempo é limitado? Talvez quanto tempo o formulário deve levar para ser enviado? Então talvez o formulário deve enviar dados para o servidor e aqui no requisito não-funcional . Além disso, ele deve enviar dados dentro de 500 milissegundos. Digamos que isso não é algo que isso que o sistema em geral faz isso Portanto, não é funcional. É algo que é constrangimento. É algo que precisa acontecer com o funcional aqui embaixo, podemos dar uma olhada no não examinado que passou mais cedo. Lembrem-se dos Send As para 56 criptografados formados de blá blá blá. Nós podemos quebrar isso para meio que quebrar isso em funcional e não-funcional. Assim, o primeiro 1 é pecado, formado a partir da frente e um servidor back-end. O que isso está fazendo? Bem, é uma função. Está pegando dados, e está mandando sua definição. O que exatamente os produtos devem fazer? E assim, para este, estamos falando de um requisito funcional. Agora, o fundo é um não funcional. Você pode ver que eu tirei toda a parte de criptografia para meio que separá-los e você verá que sempre que você estiver certo requisitos as coisas ficaram um pouco desesperadas poderia realmente combinar, e isso não é uma ciência exata. No entanto, passando por isso, você pode ser capaz de bater para fora algumas dessas coisas e figura Espere, Devemos colocar estes em duas categorias separadas. Tipo de coisas. Qualquer esperança. A parte de baixo. A parte de criptografia é a não funcional, a não funcional. Muitas vezes é referido ao seu governo não-funcional NFR, e este é fr. Muitos tiveram que tirar o são tão não-funcionais funcionais, uh, uh, mas de qualquer maneira, isso não é algo que o programa deve fazer. Não é uma operação. Não é algo que o usuário está fazendo que você saiba. Se ele não pode fazer isso, então há algo errado com o produto. É um requisito. É algo que deveria estar acontecendo com os requisitos funcionais. Assim, o requisito funcional é enviar os dados do formulário. E então o requisito não funcional é que ele deve ser criptografado que ele deve levar apenas 500 milissegundos, que ele deve enviá-lo para três servidores diferentes antes de chegar ao nosso servidor. Por alguma razão, é o não-funcional por trás disso agora. Não funcional também tem um par de diferentes categorias pequenas, e o que essas categorias são basicamente alguns dos diferentes tipos de lágrimas de não-funcional, e você vai começar a entendê-los apenas um pouco aqui. Mais ainda, o 1º 1 é os requisitos do produto, algo que o produto deve fazer novamente. Não é algo que o produto é, você sabe, agindo com o meio ambiente sem mudar algo. Esta é apenas uma maneira que o produto deve ser projetado, uma maneira que ele deve se integrar com o mundo. E digamos que você tem um cliente que é, talvez ele esteja alugando a capacidade de criar esse software, mas no final, ele quer mantê-lo sozinho. Portanto, ele precisa dele revestido em linguagem específica. Java. Não se fala de design aqui. Não há para frente e para trás. Este é um requisito. É algo que ele diz. O programa deve ser codificado em Java. É isso. Não há discussão sobre este ponto. Portanto, isso se torna um requisito agora. É a forma como o problema funciona? Por exemplo, poderíamos criar uma página da Web que tenha um formulário que poderíamos criar em Java ou CSS e HTML e JavaScript, ou talvez até mesmo python ou ruby. Podemos criar em todos esses diferentes, então não importa qual é a linguagem de codificação. Isso não faz parte da função do programa que é um requisito não-funcional, algo que temos que fazer. Mas o programa não reage por causa disso. Portanto, temos este não-funcional e é um requisito de produto. Depois entramos em requisitos organizacionais, e isso se resume às políticas e padrões, estilos e regras da organização em que você está trabalhando. Então, por exemplo, talvez a organização com a qual você está trabalhando seja uma organização militar. E dizem que sempre que os dados mudam de mãos, têm de ser encriptados. Não importa se o seu interno ou externo tem que ser criptografado. Portanto, um dos nossos crimes organizacionais. Seria que os dados do produto devem ser criptografados pela ES 2 56 E novamente, eu uso isso o tempo todo. Só porque é um algoritmo de criptografia fácil, claro,padrão militar. Só porque é um algoritmo de criptografia fácil, claro, Provavelmente vai haver alguma coisa, muito mais forte, mas não importa. Essa é a tecnologia aqui. O que eu estou falando é que eles estão nos dizendo que temos que usar isso. Ou talvez seja a política da nossa empresa. Seja o que for, não está falando sobre a função do programa e como ele interage com o mundo ao seu redor. Ele está falando sobre como ele deve ser desenvolvido e o que deve acontecer dentro do programa. E então, finalmente, para a organização que temos, o projeto será desenvolvido usando a metodologia scrum. Estamos em uma empresa que usa scrum e não há discussão sobre isso. Não há conversa sobre isso, então quando chegamos à fase de design, isso não é uma questão que não é algo que um grupo de engenheiros se reúnem e inventem. Portanto, é um requisito. Estamos em uma empresa. Ele usa scrum. Portanto, isso é um requisito. E não é falar sobre como o programa interage com o mundo, o que eu continuo dizendo, mas estou tentando perfurar essa casa. Portanto, é um requisito não funcional. Então, finalmente, entramos nos requisitos externos e isso é apenas algo. Sempre que estamos falando de coisas externas que tipo de empurrar para o nosso produto e isso pode ser leis ou regulamentos externos ou até mesmo tendências que precisamos seguir e, portanto, o que temos é que temos é que temos esses que se juntam a esses requisitos. Por exemplo, digamos que o U da União Europeia tem alguma lei, você sabe, a Lei da Liberdade, artigo um, seção dois, que afirma que todos os dados devem estar usando esse tipo de criptografia SSL criptografia entre pontos de dados ou qualquer outra coisa. Isso deve ser um requisito, porque se vamos projetar, ele é um software que estamos vendendo na U. Tem que se encaixar nisso. Caso contrário, ninguém vai comprar. E se o fizerem, seremos processados pelo governo, e nosso produto será basicamente um risco para nós, em vez de um ativo. E não queremos isso. Então isso é um requisito externo. Pode haver também certas tendências. Talvez haja uma certa tendência de segurança ou uma certa tendência, como a página da Web deve ser capaz de carregar dentro de dois segundos. Ah, muitas pessoas sairão de páginas da Web se não carregarem dentro de dois segundos. Não mostra algo que não é exatamente lei ou regulamento, mas isso é uma tendência. lei ou regulamento, Isso é algo que devemos ter culpa. Isso é algo que deveria ser implementado em nosso programa se quiséssemos ser competitivos no mercado para que pudéssemos colocar aqui e requisitos externos também. Mas essa é a última classificação de requisitos aqui. Temos aqueles não-funcionais. Temos esses requisitos funcionais. Basta lembrar um requisitos funcionais como o programa interage com o mundo ao seu redor . Está mudando alguma coisa. Está movendo algo. O usuário é capaz de fazer algo por causa desse requisito. Enquanto os requisitos não funcionais são as coisas que o programa deve ser capaz de fazer suas coisas que não necessariamente interagiram o mundo. Mas eles nos restringem. Eles nos fazem ter que fazer alguma coisa. Portanto, eles têm que ser colocados em seus documentos requisitos. 8. Introdução em modelo de 2-4: Então vamos saltar para o primeiro modelo do curso, e este vai ser um modelo que tipo de encapsula toda a produção de software . É algo chamado o modelo W. R S P M ou, para resumir, o modelo de máquina mundial. E o que este modelo, as fotos, é a interação entre o ambiente e o sistema. E isso é importante porque você tem que entender que há muitos aspectos diferentes que entram em um pedaço de software que muitas coisas diferentes que você pode não pensar que você tem que pensar ao projetar um pedaço de software. Por exemplo, sempre que você tiver um aplicativo em seu computador, você precisa ter um dispositivo de entrada e saída para se comunicar com esse aplicativo. Então, por exemplo, se estamos usando algo como um software de edição de fotos para realmente editar as fotos, nós não só temos que fazer o programa em si, mas também temos o topo do hardware em que ele é executado, que vai ser o seu computador pessoal, e você tem que ter dispositivos de entrada. Então, por exemplo, um teclado e um mouse, e em cima disso, você tem que ter o ser humano que realmente interage com tudo isso e entende como usar tudo isso. Então esta é uma maneira de categorizar isso para que possamos olhar para os requisitos de um sistema e ver se estamos perdendo alguma coisa para tipo de olhar para ele. E estamos perdendo uma suposição que deveria fazer? Há algum elemento em particular que não estamos levando em conta? Só nos permite colocar isso no lugar certo. Então, o lado esquerdo deste diagrama de Venn é algo chamado de ambiente, e é aqui que o sistema vai estar operando pensando. Por exemplo, uma equipe é algo que é usado com bastante frequência para categorizar isso. Então, por exemplo, temos uma máquina de ATM aqui, e se você mora em outro país, é uma máquina de distribuição de dinheiro. Conheço países diferentes chamados de coisas diferentes na América. Chama-se caixa automática T M. Basicamente, você vai até ele e você ganha dinheiro com isso. Muito simples, mas você tem que pensar que isso é uma equipe. Está funcionando no mundo, na esfera do mundo, e então há um programa dentro dele. Há um pequeno programa em execução, e então ele se conecta a algo lá fora. Talvez vá para um grande servidor ou bancos ou algo assim. Mas há todos esses elementos diferentes que entram nele. O lado esquerdo do meio ambiente. Em que nosso sistema está funcionando? E aqui temos dois tipos diferentes de áreas ou duas coisas diferentes que olhamos e o 1º 1 é W. E o W é Veremos que vamos passar por todas essas cartas. Aqui é o mundo. É o W bem aqui. Então o mundo, isso geralmente se resume a suposições que temos que fazer sempre que estamos fazendo um software. E estes poderiam ser realmente, muito simples e quase aspas suposições estúpidas. Mas eles precisam ser feitos, por exemplo, dentro de uma equipe que temos que fazer. Uma das suposições mundiais é que há um banco do outro lado que tem dinheiro que isso há um propósito para isso uma equipe que há uma entidade que está realmente mantendo controle dessas transações, e, portanto, a equipe tem propósito. Então, uma das suposições pode ser que existem bancos, que o dinheiro existe, que o dinheiro deles é uma espécie de entidade. Agora, é claro, você pode não ser capaz de completar você sabe, uma maneira melhor de projetar seu programa com essa suposição. Mas colocando a suposição lá, você começa a entender o programa um pouco melhor. E então você começa a coisas que são importantes, como a equipe A. Devemos ter a suposição de que a equipe A onde esta máquina estará sempre conectada à eletricidade Agora, isso é importante, porque você pode estar pensando que você quer colocá-lo em ah City que tem um talvez não o melhor rede elétrica. Talvez ligue e desligue a cada 30 segundos são 30 minutos. Talvez, você sabe, um ou dois dias por semana. Tem uma queda de energia de uma hora ou mais. É uma suposição que você tem que pensar. Certo, queremos que a equipe A se desligue? Queríamos ter uma bateria de reserva? Queremos que o programa seja reiniciado? O que queremos fazer com tudo isso? E isso é muito importante. Sempre que você está tipo de repassar essas coisas é entender essas suposições, que você não perca quaisquer requisitos, e essa é a próxima parte são os requisitos. Então o sistema é um tipo deste lado das coisas. E antes de realmente construirmos o sistema, precisamos entender em uma idéia conceitual, O que estamos construindo? O que este sistema está fazendo? Qual é o propósito? O que está tentando fazer? Que problema está resolvendo? E é aí que entram os requisitos. Isso faz parte do ambiente, porque o ambiente criou um problema. O ambiente gerou um problema, se é apenas um problema passivo, algo que pensamos, Ei, isso pode ser corrigido ou se é um problema real, algo onde havia algo que talvez os seres humanos geraram ou que a sociedade de horas extras criou e, portanto, trabalhamos. Criamos nossos requisitos. Então o próximo passo é entrarmos nesse tipo de mistura entre o ambiente e o sistema, e é aí que entramos em especificações. Então colocamos o S bem aqui. Especificações vão sobre o tipo de, um, os detalhes finos do sistema. Então ainda estamos naquela coisa do ambiente. Nós ainda estamos em resolver o problema, entanto, foram também construir o sistema foram também determinar o que a melhor coisa para o sistema é. Estamos tirando detalhes técnicos do caminho, então é aqui que a mistura que estamos construindo. Esta parte é muitas vezes referida como a interface estava construindo o ramo entre o ambiente e o sistema, o terminal para conectar o mundo a este programa. E isso, é claro, nos leva ao próximo aqui em baixo, que é o programa. E agora estamos no sistema. Então o programa é o próprio código. O programa é o que está sendo executado. São as declarações “if else”. Está controlando o hardware. Está pegando os dados. Está a enviar os dados. É isso que o programa é. Não há nada para avançar nisso, mas é uma espécie de a maior parte do desenvolvimento de software é realmente criar o programa , e é por isso que vamos falar sobre isso basicamente para o resto do curso, e, finalmente, temos a máquina, e isso é importante porque precisamos entender em que hardware está sendo executado? A máquina é a própria equipe A. Ele vê a entidade real Ah, a RAM, CPU os cabos de rede, os servidores do provedor de serviços de Internet. É tudo isso. É a entidade física em que o programa estará sendo executado. E isso é importante saber, porque talvez dissolvamos o programa que precisa usar uma Internet. , Não sei, talvez 100 megabytes por segundo. E percebemos que nenhum lugar carrega essa Internet por um tempo tempo , então precisamos retrabalhar nossos requisitos. Talvez precisemos adicionar um requisito onde ele tem que estar abaixo de 10 megabytes por segundo, coisas assim. Então isso é apenas importante considerar ao longo deste agora também é outra pequena categoria aqui, e nós podemos criar esses outros pequenos círculos assim. E o que temos com isso é que temos algo chamado E H E V E então temos, um SV S H E daí? Estes são eles apenas significa ambiente, ambiente oculto, software visível visível visível e software oculto. Então ambiente, ambiente oculto, software visível ou sistema visível oculto. E o que estes são é que eles determinaram um pouco mais de classificar o meio ambiente. Então, com o ambiente escondido, temos coisas como idéias e pedaços de dados que ah, humano sabe, por exemplo, e h seria um número PIN. Isso é um pedaço de dados. É um conceito. É algo que precisamos incorporar. Seja como for, não estará disponível para isso. O usuário não está no lado do A.T. M. é algo sobre Lee. Um ser humano sabe em sua mente. Portanto, é uma variável de ambiente, que está oculta. Então temos o ambiente visível. Um ambiente visível são as coisas que estão realmente expostas ao mundo real. Sempre que você realmente inserir esse número PIN no sistema, ele agora se torna visível. Torna-se uma citação de ervas de aço. Alguém poderia olhar por cima do seu ombro e pegar isso. Então, muitas vezes o ambiente visível são os dados que na verdade inseriram esses tipos de conceitos em sua mente quando eles são realmente inseridos no sistema. E então você tem algo conhecido um sistema visível, e isso é bem simples. São as partes visíveis do sistema. São as coisas com que interagimos em um computador que seriam o teclado e o mouse em uma máquina A T M. É o lugar onde você insere o cartão. É o bloco de caneta. São as formas de passar por isso. Então este é o tipo de fora do embora a interface, a maneira como nos conectamos com as coisas. E é por isso que você pode ver que tudo isso faz parte dessa interface. Aqui temos dados que estão saindo do abstrato, o que significa, como não concreto. É apenas informação armazenada em nossas mentes ou talvez em algum outro dispositivo entrando na interface. E com isso, entramos na parte visível da máquina. Então esta é, você sabe, a parte visível, a parte visível da máquina. Então, por exemplo, seria aquela pequena área onde ele entrou as coisas. E então temos software oculto e software oculto ou continuar dizendo software. Mas o sistema oculto é o back-end. É aquele carneiro lá dentro. Não precisamos saber o funcionamento interno de um A.T. apertamos um botão. Os trabalhos internos da equipe A fazem o que são projetados para dilatar. O mesmo com um monte de software. Nós, você sabe, se pegarmos dois lados de uma imagem que eles estavam lendo em uma imagem e nós queremos. A imagem é assim, e queremos girar a imagem para a direita. Nós clicamos em qualquer botão no nosso software que, você sabe, talvez tenha, como aquele botão de seta nele, e ele gira. Não precisamos saber o código que entra nisso. Não precisamos saber. Pegando todos os uns e zeros e aplicando uma fórmula e fazendo tudo isso. Essa é a parte escondida. O sistema visível é aquele botão que podemos apertar. E então essas coisas de novo que você quer considerar sempre que você está criando essas variáveis ou apenas, ah, esses requisitos ou o tipo de escopo do problema é apenas querer entender o que é o ambiente Escondido? Qual é o ambiente visível? Qual é o sistema visível? O que o sistema está escondido? Você está fazendo um grande pedaço de software. Essas coisas são vitais para entender a totalidade do problema. Em seguida, as palestras estavam realmente indo. Vamos continuar mergulhando nisso, então vamos continuar 9. 2-5 2-5 Profundamente: Agora temos uma melhor compreensão do modelo WRs PM pode ser uma espécie de compreensão aproximada dele. Vamos entrar em alguns exemplos e explicar cada uma dessas áreas. Então eles estavam todos na mesma página aqui, e nós poderíamos realmente implementar isso em se alguma vez tivéssemos que fazer um documento de requisitos . Então vamos entrar em cada uma das categorias e apenas queremos definí-las um pouco . Nós temos o mundo, e como eu disse, o mundo é basicamente as suposições, as suposições sobre o que estamos desenvolvendo. Eles podem ser algo que é muito, muito básico, como eletricidade é fornecida. Ou podem ser algo muito não básico. Por exemplo, com um carro, pode ser que os seres humanos saibam conduzir carros ou que os seres humanos saibam usar um pedal e um sistema de travagem. Isso seria uma suposição que precisamos saber, porque se estamos inflando um novo sistema, talvez precisemos adicionar um tutorial a ele. Talvez estejamos assumindo muito do usuário, e isso vai fazer nosso produto falhar porque nós realmente não gastamos nenhum tempo desenvolvendo um sistema ou um tutorial. Talvez isso precise ser um requisito. Um tutorial adequado que é testado é apresentado ao usuário. Isso é muito importante para um novo software que é decentemente complexo. Se você não tem um bom conjunto de tutoriais, mesmo que possa fazer coisas incríveis, ninguém o usa. Então o 1º 1 é o mundo. As suposições sobre o que estamos desenvolvendo no próximo. Outros requisitos que definem o nosso problema em termos genéricos, fáceis de entender. Precisamos saber qual é o nosso problema. Poderíamos dizer que precisamos de uma caixa automática. Poderíamos dizer que precisávamos de dinheiro não indo ao banco. É um grande problema de visão geral. Mas agora precisamos definir. O que isso realmente significa não significa que precisamos instalar pessoas em toda a cidade com as quais podemos ir até lá e conversar. Conseguir dinheiro não significa que queremos fazê-lo. Automatizado não significa que queremos tê-lo, sabe, extremamente seguro. Talvez queiramos fazer uso do acesso. Mais importante, precisamos definir o problema. Qual é o problema? Qual a solução que achamos que é melhor para resolver as especificações do problema é o próximo passo dele. Estamos definindo os detalhes mais técnicos da interface onde a construção. Então estamos realmente definindo essa interface, onde com as especificações temos esse tipo de problema definido. Sabemos qual é o problema. Sabemos quais são as suposições, e agora estamos olhando para Como conectamos o usuário com o programa? Qual é a maneira que fazemos isso? Que tecnologias devemos utilizar? Como, quais tecnologias temos que usar? Quais são alguns dos detalhes mais técnicos sobre como tudo isso funciona? Então chegamos ao programa, qual é esse o código frameworks e processo de desenvolvimento? O programa que você poderia definir como o resto deste curso indo para os documentos de design , passando sobre os aspectos de codificação reais, a manutenção do mesmo, as formas que você pode desenvolver, que esse é o aspecto do programa. E, em seguida, a máquina é ladrão hardware físico em execução. Em algum momento, se estamos construindo uma nova peça de tecnologia como em uma TM, talvez tenhamos que enviá-la a um fabricante e a um engenheiro elétrico para realmente colocar o funcionamento interno dessa coisa juntos. Caso contrário, temos esse programa que seria legal. Mas não há nada para executá-lo, então precisamos entender a máquina também. tecnologia existente deles está lá fora, ou temos que desenvolver essa tecnologia nós mesmos? Então vamos repassar um pouco de um exemplo aqui. Então o que temos é uma estação de impressão de fotos de smartphone. Vimos isto no Walmart. Talvez se você não os viu, eu descreva um pouco. É basicamente como um A T M, só que é um pouco diferente. Você tem esse tipo de , máquina aqui, e você pode subir, e você pode inserir uma unidade USB em uma pequena porta, ou você pode se conectar via Bluetooth com seu smartphone. E basicamente, o que você faz é transferir fotos para a máquina. Tem essa grande interface que com, você sabe, talvez como um teclado ou botões aqui, e quando as fotos vão lá, você as edita, e então no final, você sabe, talvez como um teclado ou botões aqui, e quando as fotos vão lá, você as edita, e então no final, na verdade imprime as fotos na parte inferior quase em tempo real. Então isso permite que você se você já saiu de férias, você tirou um monte de fotos em seu telefone. Você pode ir lá em cima. Você pode pagar. Normalmente há uma vaga de pagamento aqui, como com dinheiro ou cartão de crédito. Você paga, pega as fotos e está pronto para ir. Então essa é a máquina de que estamos falando aqui. Agora, eu recomendo fortemente que você pause o vídeo aqui e passe por isso. Eu não estou falando. Você precisa definir tudo isso. Quero dizer, isso levaria uma equipe, talvez quatro ou cinco dias para ser capaz de descobrir cada pequena idéia do que isso precisa para dilatar. Eu estou falando. Passar por cada um destes e colocar para baixo um par de coisas onde algumas das suposições que temos que fazer. Qual é o problema aqui que estamos tentando avaliar? O que o usuário deve ser capaz de fazer? O que a máquina deve ser capaz de dio? Quais são algumas das especificações? Como a máquina deve entrar em contato com coisas? O programa e a máquina. Vou te dar uma dica. Há a máquina é apenas isso e o programa é o software que estamos desenvolvendo para nós. Você realmente não precisa se concentrar em que nós realmente estamos focando é o primeiro depósito de 3 anos ir por cima disso? E como eu disse, eu recomendo fortemente isso e então eu vou rever minhas respostas para. Então eu esperava que você pausasse e você revisasse suas respostas novamente. Eu não posso me vestir. É o suficiente. Quanto mais você colocar no curso, mais você vai sair. Então, por favor, só se você quiser aprender o máximo possível, apenas faça um pouco e isso irá ajudá-lo muito, porque você pode realmente começar a implementar essa coisa. Vai fazer você se lembrar muito melhor. De qualquer forma, vamos entrar nisto. Então, o mundo, que suposições precisamos fazer? Bem, o que eu era Algumas das suposições que eu inventei são algumas muito básicas e algumas coisas que podemos tomar como garantidas. Então as pessoas têm formatos de foto padronizados, a impressão que é muito importante. Imagine se não existissem padrões ou se as pessoas estão surgindo com um realmente, realmente aleatório. Talvez cada iPhone ou telefone tenha uma maneira diferente de armazenar fotos. Isso seria que não haveria maneira de criar isso. Nós não poderíamos ter, Ah, sistema que decodifica você não tem 800 tipos de fotos. Simplesmente não funcionaria. Então eu estou fazendo a suposição de que existem formatos de fotos muito padrão para imprimir. As pessoas serão capazes de ler os prompts e tutorial. Os humanos são basicamente alfabetizados. Isso é o que acontece é que haverá em um idioma que as pessoas podem ler e entender. Se você foi para uma parte mais analfabeta do mundo, talvez em algum lugar que não haja muita educação ou conhecimento de leitura. Talvez isso seja um problema para você. Talvez haja alguma outra maneira que você possa implementar isso com fotos ou algo que os ajudaria melhor. Agora, com prazer. Algumas partes do mundo estão desaparecendo com mais educação, mas isso é algo que você pode querer manter na parte de trás da sua cabeça. Algumas partes do mundo estão desaparecendo com mais educação, Hum, o próximo é histórias vai re materiais adicionais. Assumimos que alguém vai entrar nisto e reabastecer as tintas e o papel e coisas assim. Estamos assumindo que vamos colocar isso em lojas onde as pessoas realmente fazem isso caso contrário teria que encontrar alguma solução e rede de distribuição para garantir que este ar sempre reabastecido. Então essa é uma boa suposição. Isso é algo que precisaríamos ter certeza. É uma suposição adequada ou, bem, precisamos desenvolver algo assim. As pessoas têm cartões de débito que funcionam com tecnologia de cartão de débito padrão ou neste cartão de crédito ou qualquer tecnologia de cartão ou dinheiro. Nesse caso, haverá uma moeda comum que podemos usar nesta máquina que funcionará. Haverá eletricidade prontamente disponível que é importante. Sem eletricidade, esta máquina não funcionaria e eles estarão disponíveis. INTERNET. Talvez esta máquina precise de contactar os servidores. Talvez ele não tenha o hardware nele para fazer as edições de fotos e realmente envia para um servidor de servidor. Faz a foto edita e, em seguida, envia os dados de volta. Isso é muito comum hoje em dia, então nessa situação podemos precisar de Internet. E se executarmos um país como o que pode não funcionar, podemos não ter Internet disponível lá, e podemos ter que colocar em um secundário, um pouco de poder de processamento, e isso apenas no caso de não tem Internet, ele pode tentar fazê-lo aqui. Só vai demorar um pouco. Ou talvez haja outras soluções que possamos encontrar. Essa é uma suposição importante para reconhecer a próxima parte dos requisitos. O que é que a coisa deve dialogar? Então, é um usuário pode conectar um smartphone ao sistema. E se você notar que talvez você queira rever os requisitos primeiro antes de saltar para o mundo, talvez você queira tipo de definir o problema e então entender tipo de trabalho fora disso e ver, como, quais são algumas das suposições que fiz ao fazer os requisitos que poderiam ser um bom conjunto para essas coisas poderiam ser feitas de muitas, muitas maneiras diferentes. Apenas algumas idéias aqui, qualquer maneira, requisitos que o usuário pode conectar um smartphone ao sistema. O smartphone em imagens de transferência sobre o usuário pode editar fotos. As fotos podem ser impressas por máquina, e o uso pode pagar pelo serviço. Em geral, se você tiver dúvidas sobre os requisitos, basta passar por cima de um caso de uso, basicamente uma maneira de usar a máquina. Se você fosse até esta máquina, como você iria querer usá-la? E como você gostaria que as coisas interagissem? Essa é uma ótima maneira de começar com os requisitos a cada passo. Basta anotar e então você poderia tipo de construir a partir daí as especificações da próxima parte . Então agora temos esse tipo de idéia aqui de alguns dos requisitos. Agora vamos para um pouco mais do nitty corajoso. Como nos conectamos a ele? Será azul para a tecnologia? Então um smartphone se conecta. Essa é a maneira mais popular de se conectar. Então Bluetooth seria uma boa ideia. E precisamos de um protocolo de transferência Bluetooth adequado para ser instalado e para tornar a transação segura para que ninguém mais possa entrar lá. Precisamos de um apropriado ou o sistema terá uma suíte de edição de emulação de dados de fotos. Isso é importante. Precisamos definir nossa suíte de edição. Queremos comprá-lo de outra pessoa que queira projetá-lo nós mesmos? Este sistema usará criptografia e tecnologia de chip para entrar em contato com servidores financeiros. É uma ótima coisa de se saber. Como é que vai contactar os bancos? Como é que vai usá-lo? Estamos usando essa criptografia e essa tecnologia de chip. Então, estamos especificando a maneira exata que as transações financeiras vão acontecer. E, em seguida, o sistema terá dispositivo de impressão padrão para imprimir fotos. Então vai haver uma maneira de imprimir as fotos. Podemos ser capazes de definir isso ainda mais em profundidade quando começarmos a desenvolvê-lo. E, finalmente, temos o programa, que eu disse que é apenas código de sistema e máquina, que são apenas as especificações do sistema , a RAM , o processador, etc. No geral, porém, isso é uma espécie de o que você faz com World Model em apenas quero dizer, isso me levou talvez 10 minutos. Na verdade, temos uma espécie de plano para o que queremos fazer com essa coisa que temos em uma idéia geral. Ninguém vai por todo o lado com a forma como deve ser construído. Todos poderiam ficar na mesma página, e poderíamos apresentar isso e resolver isso ainda mais. Nós poderíamos realmente começar a passar por essas coisas e realmente desenvolver, como um pouco de documentação, talvez como uma coisa de 20 páginas definindo o problema para encontrar como queremos resolver o problema definindo as especificações e talvez até mesmo as especificações do sistema do que seria de que poderíamos desenvolver um orçamento. Poderíamos desenvolver o que as equipes precisam estar nele. É um ótimo ponto de partida, e tudo isso é muito importante para os requisitos para encontrar nosso problema. Prepará-los e, em seguida, preparar-se para passar para a próxima fase é como projetar e realmente revestir a coisa. 10. Exemplo de requisitos: Então vamos terminar esta seção com outro exemplo de exemplos são realmente importantes porque eles nos permitem realmente sujar nossas mãos e fazer a coisa para realmente passar por alguns requisitos. Isso é muito útil, porque muitas dessas informações podem entrar em um ouvido e sair pelo outro. Mas se você realmente fizer um exemplo, então você pode realmente cimentar isso em sua mente. E sempre que algo surgir, você vai se lembrar talvez não de todos os requisitos e as definições entre os dois Mas você se lembra o suficiente para deixar a fiança para fazer uma pesquisa inteligente do Google para ele, . ou você será capaz de fazer um esboço e, em seguida, procurar talvez algumas outras coisas que você deve incluir em sua documentação de requisitos. Então, com este exemplo, o que vamos dializar é que basicamente vamos pegar, tipo, um cenário do mundo real e apenas trabalhar através dele com esses exemplos. Lembre-se, não estamos tentando ficar 100% aqui. Nós não estamos tentando. Pense em todas as possibilidades concebíveis no mundo real que você poderia, mas isso geralmente leva semanas para fazê-lo em que essas coisas estavam apenas tentando sair. Os 80% estavam tentando derrubar, você sabe, os 80% dos requisitos que podem ir para isso e então, você sabe, se você realmente quiser, você pode sentar mais tarde e fazer o resto disso. Ou podemos simplesmente seguir em frente e tipo de construir sobre isso à medida que avançamos. Então o que temos é que ainda não construímos um aplicativo de xadrez. Então vamos dizer que temos um telefone e onde fomos encarregados com um aplicativo, basicamente peito. Então você sabe, xadrez, o jogo de xadrez. Se você não sabe o que é xadrez, invente qualquer jogo que você conhece. E então nós temos um aplicativo de jogo, e queremos rentabilizar este aplicativo para começar a ganhar dinheiro. Então esse é o nosso objetivo é levar este aplicativo o que quer que seja, como ele funciona, Talvez haja. Talvez seja um online no. Talvez seja qualquer coisa. Vamos pegar esse jogo e começar a monetizar, então precisamos pensar sobre quais outros passos devemos tomar. Como devemos definir o problema e o que irá beneficiar tanto o cliente como os usuários e com tudo isso, podemos usar esse modelo mundial novamente. Lembre-se, vamos procurar o mundo. Então, as suposições que vamos procurar os requisitos. Então, o que exatamente é necessário deste aplicativo, e então nós vamos procurar essas especificações. Então, quais são alguns dos detalhes técnicos de como queremos implementar isso em quais são algumas das limitações que temos de seguir? Digamos que o aplicativo anterior é construído em Java e o cliente quer mantê-lo dessa maneira. Então, é quando as restrições que eu posso lhe dar também, qualquer maneira, seria muito benéfico para você pausar o vídeo e apenas passar por estes três aqui. E se você notar que não falamos sobre como rentabilizar a saída. Então, venha com algo, venha com uma idéia sobre como você pode rentabilizá-lo. Talvez não haja anúncios nele e você deseja adicionar anúncios Pode ser sua idéia deste aplicativo. Já é anúncios Hades E você quer adicionar algum modelo de assinatura? Ou talvez você queira criar uma versão paga. O que iria na versão paga vir acima com uma idéia sobre um aplicativo e, em seguida, como você pode avançar esse aplicativo e, em seguida, tipo de chegar com as suposições, os requisitos e as especificações sobre isso. E mais uma vez, é um exercício. Apenas seja criativo, divirta-se um pouco com ele, talvez passe cinco minutos nele e depois volte e você pode ver como eu fui com ele. Podemos comparar, uh, ver as diferenças sobre como isso e você também vê que há um monte de maneiras diferentes de fazer tudo isso, depositar vídeo, fazer isso e voltar logo. Tudo bem, então espero que você tenha feito isso porque eu acho que fazer isso sozinho e depois vê-lo novamente será uma ótima maneira de cimentar essa informação na sua cabeça. Então a primeira coisa que eu passei por cima foram as suposições do mundo, as coisas que assumimos sobre este aplicativo, as suposições são importantes porque ele nos permite definir os requisitos com as suposições foram então capazes de descobrir que não Nós não temos que definir, você sabe, requisitos bobos como telefones existem ou algo assim. Vamos precisar criar um telefone que possa suportar abside com suposições. Assumimos que o mundo é de uma certa maneira e isso nos permite colocar essas coisas em uma caixa em outro lugar e realmente trabalhar nas coisas que nos ajudarão. Então, nesta situação, temos que há uma maneira de pagar em smartphones. Tem que haver algum serviço financeiro em smartphones. Para que possamos fazer essas transações, há maneiras de ganhar dinheiro com um APP. Tem que haver alguma técnica de marketing viável lá fora para ganhar dinheiro com um APP. Se esses dois não existirem, teremos que inventar tudo isso nós mesmos. E essa tarefa de repente fica muito, muito grande porque agora os requisitos terão que detalhar como você sabe como é o mercado , quais são os riscos potenciais, coisas assim. Mas se nós podemos assumir que ambas as coisas existem, então nós só temos que pensar em Ok, quais são as melhores maneiras de fazê-lo, então? O aplicativo é extensível. Talvez a base de código tão ruim que não há nenhuma maneira de estendermos o aplicativo para outra coisa, então vamos supor que é extensível. Caso contrário, esse projeto vai parar na água. Não vai a lugar nenhum. Haverá a capacidade de entrar em contato com a Internet e a instituição financeira. Então, o telefone tem recursos de Internet novamente. Não precisamos definir uma nova maneira de os telefones se conectarem à Internet. Vamos presumir que tem capacidades de Internet. A destruição da transação poderia ser segura o suficiente. Vamos supor que há uma maneira de garantir transações. As pessoas estão fazendo isso por todo o lado com transações diferentes, então provavelmente há uma maneira de torná-las seguras. O telefone terá poder de processamento para lidar com a solicitação. Esperamos que esses pedidos sejam baixos e que o poder de processamento esteja lá. Se não estiverem, teremos que esperar por novas tecnologias. Diferentes moedas poderão ser aceitas. Temos um aplicativo em todo o mundo. Então talvez esperemos que haja moedas de todo o mundo que possam ser transferidas de alguma forma. Talvez, por exemplo , digamos que o mercado só nos aceitou dólares. Isso mudaria nossa abordagem uma tonelada. Mas se assumirmos que há uma maneira de aceitar moeda de todo o mundo, então nem precisamos pensar nisso. Esperemos que o mercado faça isso sozinho, e então é legal aceitar o pagamento por telefone. Isso é importante porque talvez haja algum país onde não seja legal aceitar pagamentos sem que eles estejam pessoalmente ou algo assim. Então precisamos entender as leis para não nos metermos em problemas legais. Precisamos entender que, o que quer que estejamos fazendo é um processo legal que não precisamos envolver os baixistas. Nós não precisamos mudar leis ou preencher alguns formulários para torná-lo legal. Então isso é importante para assumir e algo que você deve pensar com os requisitos apenas para o caso. Por exemplo, se você está pensando em coletar dados, talvez você precise se certificar de que há uma política de privacidade. Talvez isso precisa ir para suas necessidades é que é legal com uma política de privacidade, Então agora você tem que colocar em que o requisito. Então sabemos, então temos nossas suposições mundiais. Em seguida, são os requisitos. Então eu fui fazer coisas que achei que funcionariam. Acabei de pensar em um aplicativo que já tinha anúncios. E então um modelo de assinatura removeria os anúncios algo muito, muito simples. Assim, o recurso pro removeu anúncios para o usuário que estou definindo. O que exatamente são recursos profissionais? Vai fazer algo simples. Ele vai apenas remover, adicionar Então esse vai ser o nosso recurso profissional bem ali. Então, o próximo passo é que o recurso deve aceitar o pagamento de um usuário. Isso é muito importante se ele não aceitar o pagamento de um usuário do que não há nenhuma maneira que nós podemos realmente cobrá-los onde não há nenhum lugar que nós obter amigo. Portanto, não devemos dar nada ao usuário. O recurso deve fornecer recursos profissionais após a transação bem-sucedida. Poderíamos aceitar o dinheiro da pessoa e não fazer nada no APP. Em seguida, o nosso aplicativo provavelmente vai ser encerrado na loja de APP, por isso devemos ser capazes de fornecer os recursos pro em um sucesso e que é importante uma transação bem-sucedida. Precisamos verificar se é bem sucedido ou não. O professor deve concluir as transações de forma segura novamente. Não queremos violações de dados. Isso é ruim para todos. Isso é ruim porque permite que outras pessoas sejam exploradas e é ruim porque nos faz parecer mal. O recurso ou vote pro recursos assim que uma assinatura se tornar inválida. Então, se alguém parou de pagar, devemos remover os recursos. Caso contrário, alguém vai apenas fazê-lo pela primeira vez e, em seguida, apenas nunca pagar novamente e ainda obter todos os recursos pro. O recurso fornecerá um botão de cancelamento dentro do APP. Isso não é algo que você tem que fazer. Talvez hoje em dia, no tipo de aplicativo que está começando a se tornar algo que você tem que dio. Mas talvez com nosso aplicativo, valorizamos a confiança em nossa empresa. Então nós vamos ter aquele botão de cancelamento dentro do aplicativo que vai enviar um sinal que cancela a assinatura para todos os meses futuros. O habitual estender a base de código existente. Nós não queremos redesenhar este aplicativo, então vamos tentar estendê-lo fora da base de código atual. O recurso não deve adicionar mais de cinco megabytes ao tamanho geral do download. Talvez isso seja algo que o chefe geral disse. Ou talvez seja algo que o cliente disse que nosso aplicativo já é realmente grande e as pessoas estão reclamando sobre isso, então não pode ser mais do que cinco megabytes, algo que pode acontecer. Então eu joguei-o lá, e o recurso deve completar a transação em tempo hábil. Não queremos que seja um recurso muito, muito lento. Então nós temos essa idéia de que ele deve ser completado em tempo hábil e, em seguida, com suas especificações, nós podemos realmente tipo de ir para isso um pouco mais em profundidade. Então agora temos as suposições do mundo. Temos os requisitos, e agora temos as especificações. O recurso será codificado em Java com a linguagem APS existente. Lembre-se, o que falamos é que o APP foi codificado em Java, então isso é uma especificação na tecnologia. Quando você visualiza é a linguagem APS existente, nós não seria talvez nós não temos que especificar trabalho nestas especificações. Poderíamos apenas dizer a linguagem APS existente, mas eu gosto de ser meio contundente e realmente, realmente transparente e esse tipo de documentos, o recurso usará a loja de jogos Android para suas transações. Isso é algo que você sabe, há um monte de maneiras diferentes que você pode aceitar o pagamento. Você poderia, por exemplo, implementar algo chamado stripe, que é uma tecnologia que aceita pagamentos. É um software de transação. Mas para esta situação, o que vamos fazer é usar a loja Android Play para fazer todas as transações . Se quiséssemos fazer isso aconteceu, talvez IOS também. Usamos a loja de maçãs lá. A verificação Futural para assinatura ativa diariamente usando o Google forneceu um P I. Isso é muito técnico, mas algo que é importante algo que os desenvolvedores precisam saber é quantas vezes queremos verificar para ver se um ainda é válida? Estávamos dizendo que usaremos o Googles AP I para checar diariamente. Se a descrição for válida, não faça nada de que ela seja inválida. Tire os privilégios. Ou talvez colocar um período de carência. Algo assim. O recurso será desativado. Adicione a máfia. Uma vez que a chave de assinatura se torna válida, add mob é uma forma de publicidade dentro de seu APS. Pode estar se movendo para alguma nova tecnologia quando você assistir isso. Talvez esta seja uma tecnologia que tipo de extinta que ninguém usa mais, mas tudo bem, Tudo o que estou dizendo é que temos essa tecnologia em nosso aplicativo, e estamos dizendo que uma vez que a chave de assinatura se torna válida, nós remover esse tipo de. Nós removemos essa tecnologia da APP para que o usuário tenha esses recursos profissionais. E então este é o último, aquele aqui em baixo em tempo hábil. Digamos que nós, por alguma razão, temos um temporizador que deve ser capaz de completar em 500 milissegundos. Depois de clicar no botão OK novamente, talvez isso seja transmitido pelo cliente. Ou talvez seja algo que sua empresa gosta de fazer. Eles têm esse tipo de idéia de solidez e querem defini-la. Portanto, nesta situação, temos a exigência de que deve ser oportuna para as especificações. Nós meio que damos a exatidão disso e isso. Como eu disse, não é um exemplo 100% aqui, mas imagine se você tivesse apenas este documento para sair, e alguém lhe entregasse este documento e dissesse, eu quero que você codifique isso. De repente você tem uma direção muito forte do que você quer fazer. E agora você também tem a capacidade de fazer perguntas. Eles definiram talvez 85%. E talvez você venha para uma situação em que, como, não há nada aqui e agora você pode realmente fazer as perguntas apropriadas para o seu cliente ou para o seu negócio de Ei, que cor devem ser os botões, ou algo assim que não foi definido em nenhum lugar aqui? É algo que eu deveria escolher? É algo que vocês querem escolher, etc. Então, chegando com este documento de requisitos, é uma ótima maneira de uma ótima base para construir software. Em seguida, vamos para a cara do design. Então, uma vez que obtemos tudo isso, é hora de realmente descer um pouco no nitty gritty e começar a rever como , exatamente nós queremos construir qualquer pedaço de software que estamos tentando construir. 11. Introdução à arquitetura: Vamos começar com o mais alto nível de design e por mais alto nível, quero dizer o menos específico. Então, por exemplo, se você estiver projetando uma cidade, você pode começar por zonear as diferentes áreas. Queremos um pouco residencial aqui. Queremos um comercial aqui. Queremos alguma indústria aqui, nada mais. É um plano muito, muito básico sobre como a cidade pode funcionar. E é assim que a arquitetura funciona. Nós estamos tirando isso de requisitos e agora realmente tipo de chegando com uma idéia sobre como o aplicativo deve funcionar. E é por isso que a arquitetura é o mais alto nível, ou o nível mais alto de design. Arquitetos são a ligação entre ideia e realidade, então arquitetos são pessoas que implementam arquitetura. Digamos que você tem um prédio que vai construir antes de abrir terreno. Antes mesmo de você ter alguma idéia ou qualquer pessoa no local para construir este edifício, você vai criar alguns projetos. Haverá basicamente engenheiros que testam as diferentes partes, como dizer que precisamos de pelo menos um raio de 15 pés aqui ou precisamos deste tipo de construção aqui e você vai usar basicamente este projeto para construir o prédio. Nada está sendo implementado ainda. É apenas um design, e é isso que o arquiteto está fazendo. Alguém teve uma ideia para um prédio. O arquiteto pega nessa ideia e constrói um plano para colocá-la em realidade. É por isso que eles são a ligação entre ele. Eles não são realmente os que estão criando, e eles não são os que você normalmente inventou. A ideia. São eles que estão construindo essa ligação entre os dois para que uma equipe de construção possa construí-lo, e a pessoa que teve a idéia pode vê-lo construído. Então essa é a importância dos arquitetos e da engenharia de software. Muitas vezes temos que nos tornar os arquitetos, então temos que pegar nosso documento de requisitos, e temos que transferi-lo para um plano sobre como realmente construí-lo para que nós novamente talvez com um programador de software também. Podemos implementar a ideia. Essa é a importância da arquitetura é fornecer esse link. Agora a arquitetura é importante. É algo que não pode ser corrigido, uma vez implementado ou em software no papel mundial que não pode ser consertado e engenharia de software Pode ser muito, muito, muito difícil de consertar, mas uma espécie de vê-lo como algo que não pode ser corrigido. Uma vez implementado em software, arquitetura ruim é algo que não pode ser corrigido com uma boa programação. Se você projetar a arquitetura de um aplicativo mal, não importa o quão bons seus programadores são, ele ainda vai sair como um produto pobre que leva muito tempo para manter, e que é muito difícil de estender e melhorar com o tempo. Imagine tentar consertar a base de um arranha-céu depois de ter 20 andares de altura. Então digamos que eles começaram a construir este arranha-céu e eles são sobre esta altura. Você sabe, eles ainda são guindastes indo e realmente construindo a coisa, mas eles percebem que há um problema fundamental. A coisa em que o arranha-céu é construído tem um problema. O que você faz para consertar isso? É muito mais difícil consertá-lo quando você tem 20 andares acima, então quando você tem o dedo da base, olhe para ele ir. Na verdade, esta fundação não vai funcionar. Vamos destruir e reconstruí-lo rapidamente. Será um tempo de resposta muito rápido aqui em cima, embora você tenha que projetar alguma maneira de consertar a base sem destruir o arranha-céu. Ou talvez a única maneira de consertar isso é você ter que derrubar tudo antes de poder construí-lo novamente. Isso é muitas vezes o que acontece e engenharia de software também. Temos que acabar com um projeto e começar de novo. Então a arquitetura é muito importante. Vamos meio que quebrar isso e apenas saltar para talvez um pouco mais de um exemplo orientado por software . Digamos que temos este servidor aqui mesmo que leva em nosso aplicativo. Digamos que temos um componente aqui, algo que nosso aplicativo faz, e ele entra em contato com essa taxa de servidor assim. E digamos que temos outro componente aqui, e ele entra em contato com o administrador. Recebe feedback, e depois temos outro aqui em baixo contacta este. Ele entra em contato com isso, e então isso sai e entra aqui, e este vai até lá e você sabe, então nós temos esse tipo de aplicativo realmente complexo que não tem um monte de, hum, tipo de coisas. Tem um monte desses, como barras transversais que podem entrar e ao redor. E assim você pode ver que a arquitetura, este aplicativo pode não ser o melhor. E por que não seria o melhor? Bem, digamos que temos um problema com nossa interface central, nosso servidor núcleo, que a maneira que projetamos, talvez seja inseguro. Talvez haja uma maneira fácil de hackers invadir isso, e a única maneira de corrigi-lo será substituindo o servidor e alterar todos os protocolos. Bem, com uma arquitetura como esta, imagine tirar esse componente e colocar um novo por causa da maneira como ele está ligado tudo aqui, nós vamos ter que re programar cada um desses pequenos passos cada tipo de Lupin aqui que contacta este servidor central. Não podemos trocar o servidor a quente. Temos que re programar todo o nosso aplicativo. Cada componente tem várias áreas que teríamos que basicamente re programa para começar a funcionar corretamente novamente. Então, neste sozinho nós teríamos que talvez programar estrada três ou quatro pontos de extremidade diferentes, e então quando eles vêm aqui e saem, o outro lado teria que re programar que como esses dados recebem, como esses dados os recebem poderia ficar muito, muito complexo. E você chega a um ponto em que você olha para o software e você vai, não há como nós podemos mudar isso, também. Nós vamos ter que ficar com um software inseguro ou apenas vamos ter que destruí-lo e começar completamente de novo ou abandonar o software e basicamente simplesmente não apoiá-lo mais. Isso também acontece uma quantia decente. Arquitetura, muito, muito importante. Vamos repassar algumas maneiras que você pode criar a idéia sobre a arquitetura e uma espécie de refinar isso para baixo. Então você tem pelo menos um bom entendimento sobre essas coisas. 12. Visão geral de arquitetura: Vamos começar nossa discussão sobre arquitetura com a razão pela qual queremos cobri-la. E isso é arquitetura de software. Como a arquitetura se aplica ao processo de desenvolvimento de software? Nós vamos software Arquitetura é tudo sobre dividir sistemas maiores em sistemas menores e focados. Isso nos dá muitos benefícios diferentes, não só para reduzir custos, mas você ajuda a facilitar o desenvolvimento para ajudar a torná-lo assim. Nossos engenheiros não estão esperando ociosamente por outras pessoas, pessoas e tantas outras coisas diferentes. Então, alguns aspectos chave aqui é que uma boa arquitetura é difícil. Não é algo fácil que todos possamos fazer. E é por isso que muitas pessoas evitam fazer essa parte porque é preciso um pouco de pensamento, alguma criatividade para criar uma boa arquitetura. E muitas pessoas só querem entrar lá e começar a codificar para que nem pensem na arquitetura. E quando você faz isso, você constrói algo que é conhecido um código de espaguete onde você começa a construir um arquivo e então você constrói outro arquivo e você diz: “ Espere, Espere, isso precisa de um link lá. Então temos outro arquivo e, tipo, oh, que precisa ligar lá também. Mas ele também precisa se vincular a este arquivo. E lentamente você começa a ter essa web, essa teia de espaguete de código indo juntos e em vez de ter essa arquitetura agradável, sabe, sabe, talvez organizada onde talvez tudo entre em contato com um servidor central ou há ah , página de constantes que tem tudo. Então, se quisermos mudar algo, só temos que mudá-lo. Um lugar. Você começa a receber essa estranha teia de chamadas e coisas assim e torna-se muito difícil de rastrear problemas porque talvez o problema comece aqui, e ele chama a função errada aqui, o que então faz com que quebre um aspecto aqui o que faz com que ele volte aqui e chame outra função errada, vá até aqui e depois aqui. Então é aqui que achamos que o inseto está. E agora temos que rastreá-lo através de todas essas chamadas para descobrir que Oh, não, na verdade era uma linha de código aqui. Nós estamos aqui. Temos menos dessas conexões, e talvez a ruptura seja aqui em cima. Ou talvez o freio esteja aqui em baixo e ele se manifesta Aqui podemos fazer um rápido olhar para trás e vemos que está bem aqui. Agora, é claro, esse ar é como coisas muito hipotéticas. Mas isso acontece. Muito é que, se tivermos uma arquitetura muito limpa, as pausas são fáceis de encontrar. Uma boa arquitetura também permite um desenvolvimento mais rápido e uma alocação de tarefas mais inteligente. Isso é importante porque ele e depois dizer que é o ponto que ele vai nos poupar dinheiro ao longo do tempo. Se pudermos dividir nossa arquitetura em algo assim, então podemos dizer que teremos um engenheiro trabalhando em uma tarefa aqui, engenheiro para engenheiro. 34 e cinco. Nós temos cinco tarefas diferentes desenvolvendo ao mesmo tempo onde se nós apenas temos um arquivo gigante, ou talvez até, como apenas dois arquivos gigantes que tipo de comunicação para frente e para trás um com o outro, como nós estávamos indo para obter cinco engenheiros trabalhando tarefas diferentes. Bem, nós poderíamos tê-los, você sabe, talvez todos trabalhando no mesmo arquivo ao mesmo tempo, mas isso na verdade causaria geralmente conflitos de fusão, o que significa que, que significa que, como eu trabalhei em código aqui em cima, Ele trabalhou no código aqui, mas para conseguir o trabalho dele aqui em baixo. Ele ou ela teve que ir em frente e mudar alguma coisa aqui em cima. Então, agora eu empurro o meu código, ele empurra o seu código, e de repente há um grande conflito. Estou mudando o código. Ele está mudando o código, e nós realmente temos que nos unir e ir linha por linha para corrigi-lo. É um processo muito doloroso. Então, nessa situação, o que muitas vezes acontece é que se ambos precisarmos trabalhar no mesmo código, você só tem que esperar. Então, você sabe, Engenheiro Um completa sua tarefa, projetado para completar sua tarefa. E agora a engenheira três pode finalmente pular lá e começar a completar sua tarefa. Portanto, é algo que reduz o tempo de inatividade geral. Se obtivermos boa arquitetura e permite que a empresa também decida onde comprar e onde construir . Se nós temos algo assim e fôssemos tipo, nós só temos talvez quatro engenheiros, bem, talvez haja uma boa solução lá fora, e nós não precisamos gastar todo o tempo desenvolvendo-o Então e disse, nós Apenas diga OK, vamos trabalhar nisso e vamos em frente e comprar algo que se encaixe nisso. Talvez seja uma forma ou algo assim. Há muitas, muitas grandes coisas de forma on-line formando pequenos projetos que poderíamos comprar e integrar em nosso software que nos permite sapatilhas de dedo do pé que o comprador construir. E então, no geral, sempre precisamos lembrar que erros de arquitetura são quase impossíveis de corrigir uma vez codificação começou. Uma vez que começamos, é impossível pegar isso e tornar aquilo e tudo o que eu disser impossível. Não quero dizer que não seja possível. Não há nenhuma maneira de você fazer isso. O que quero dizer é que custaria ao Maurin tempo e dinheiro para consertar isso, que seria construir um novo produto como este. Então, por exemplo, se tivéssemos um produto existente aqui para torná-lo assim, teríamos que gastar mais dinheiro do que seria necessário para começar de novo para excluir tudo e começar de novo. E é isso que quero dizer quando digo afixos impossíveis que custam desespero Insee entre os dois. Então vamos passar como um pequeno exemplo aqui, algo sobre o qual podemos ter uma ideia. Digamos que estamos criando um site, e então começamos com essa arquitetura ruim no início. Então nós temos uma única página web que tem talvez 1000 linhas de código nele. Ou para este exemplo, é ele. Tem 10.000 linhas de código nele. Se eu te encarregasse de encontrar um certo elemento aqui, quão fácil você acha que seria? Quantas chamadas diferentes você acha? Para onde você teria que ir daqui, até aqui, até aqui. Você acha que aconteceria sempre que você fosse a um documento de 10.000 linhas? E este é um pequeno site? Quero dizer, eles são seus sites que têm 100.000 linhas de código. Imagine que eles estão todos em um único. Como você iria separá-lo para que eu não sei, talvez 15 engenheiros possam trabalhar nisso. Pensa nisso. Digamos que o próximo passo está tudo bem. Não queremos nosso site inteiro em uma única página, então, em vez disso, vamos ser como o quê? Precisamos de um, digamos, um front-end. Então temos o front-end, e depois precisamos de uma volta. Então agora criamos arquivos populares. Nós temos a frente e a parte de trás, e eles se comunicam um com o outro ficando um pouco melhor. Agora podemos colocar uma volta em engenheiro aqui, uma frente e um engenheiro. E se tivermos, por exemplo, um botão aparece como a cor errada, sabemos que talvez vamos olhar para esta pasta em vez desta pasta. Você sabe, este tem talvez 5000 linhas ou nesta situação, 50.000 linhas. E este tem 50.000 linhas. Torna só um pouco mais fácil de descobrir. Não precisamos passar por 50.000 linhas de coisas que nem importam. Nós só temos frente e tal. E agora podemos começar a separá-lo e fazer em vez de apenas front-end. Talvez tenhamos as páginas da Web divididas, então temos uma página principal aqui. Talvez tenhamos a página de login aqui, e então temos o formulário aqui. E talvez o formulário esteja em Lee Ah, 100 linhas. E então a página principal é, você sabe, talvez 49.000 linhas e, em seguida, a página de login é algo como, você sabe, talvez 900 linhas. Então ainda são aquelas 50.000 linhas, mas nós temos e então vamos manter o final acabado. Aqui está o back-end. Sim, isso deveria ter sido de volta e não apenas end Eso front-end backend. Então temos o back-end aqui que ainda está se comunicando. Mas agora temos uma idéia um pouco melhor sobre como ele está se comunicando com as coisas. Agora temos isso quebrado um pouco mais. Então temos a capacidade de que se dissermos que a cor do botão está errada, podemos entrar no arquivo mais como, Bem, está na página do formulário. Vamos ver a página do formulário. Lemos as 100 linhas ali, fazemos a mudança. Então você vê, medida que nós dividimos mawr e mais e mais, nós começamos a ser capazes de manter este projeto um pouco mais, e começamos a ser capazes de basicamente criar um produto melhor que nós podemos expandir no futuro. Então agora nós temos apenas uma espécie de uma idéia muito, muito geral do que estamos fazendo com a arquitetura. Ao quebrar as coisas, vamos começar a rever alguns deles que eles chamaram padrões ou modelos diferentes maneiras que você pode pegar seu projeto e quebrá-lo e alguns dos tipos de métodos testados e verdadeiros de fazer isso. 13. Padrão de tubulação e filtro: Vamos repassar nosso primeiro padrão arquitetônico. Então, os padrões arquitetônicos nunca há realmente uma abordagem de tamanho único, o que significa que não podemos olhar para um padrão e desenvolver cada pedaço de software com esse padrão. Então, com esses padrões, o que estamos criando aqui é que estamos criando uma caixa de ferramentas que podemos construir. Então, se entendermos, talvez cinco ou seis padrões populares sempre que chegarmos a um problema entenderão como exatamente devemos ir sobre isso, ou pelo menos uma direção geral de onde devemos ir. E então para esse problema específico. Podemos desenvolver uma arquitetura para isso. Então não pense que você poderia apenas aplicar esses padrões, você sabe completamente e totalmente de um projeto. Estes são novamente. Eles são uma espécie de idéias, suas maneiras de que as coisas poderiam ser feitas. E você poderia pensar em um problema. Tipo, “Oh, yeah, eu vou usar um pipe e filtro e, em seguida, um servidor cliente e então, você sabe, tipo de ligá-lo junto com a minha própria arquitetura. Então, só com esse pequeno aviso, vamos começar com isso. O 1º 1 como eu disse, é o padrão de tubo e filtro os tubos são as conexões de dados. E os filtros são coisas assim. Divisível por 10. Mesmo estranho. Então, por exemplo, se tivéssemos um pequeno conjunto de dados bem aqui, se tivermos, tipo, um pequeno conjunto de dados de 357, poderíamos enviá-lo para o nosso primeiro filtro, nosso segundo filtro. E então talvez essa seja a saída. Então estes aqui são os canos. Então este aqui é o tubo, e estes aqui são os filtros. Agora, há um aspecto importante que temos de rever. Há algo muito importante com estes tubos e filtros. A entrada deve corresponder à saída. E o que eu quero dizer com isso é que eu não quero dizer que, você sabe, 357 tem que ir em todos os filtros, e então 357 tem que sair. O que quero dizer é que o mesmo tipo de entrada precisa sair de cada um destes para que possamos fazer isso completamente e totalmente tipo de mistura de ervas enfraquecer. Pegue isso e coloque esse aqui. Podemos pegar isso e colocar esse aqui. Podemos adicionar mais cinco. Só podíamos fazer uma. Essa é a parte importante. Então, por exemplo, se temos 357 e ele entra em um, isto é, por exemplo, Times 10 ele vai sair com um exemplo de 30 50 70. E então isso vai para o próximo filtro. Já reparaste que é exactamente a mesma coisa? É só mais um conjunto de números, talvez para este em vez de vezes. Ted, dizemos que o Onley quer talvez. Vamos pôr outro número aqui para que funcione. Só queremos estranho. Então isso sai e agora vai ser 357 e isso vai para o próximo. A mudança de tamanho. Isso é perfeitamente bom. Mas o tipo permaneceu o mesmo. Eles ainda são apenas sentido numérico, e novamente, eu vou continuar dirigindo isso para casa. Isso é o tubo e filtro é tudo sobre. Você pega em um determinado tipo, você colocá-lo através de um filtro e você obtém um certo tipo de volta para fora da outra extremidade. E então, com o tubo e o filtro, também podemos aplicar ações. E o que eles são é que eles apenas pegam os dados e eles fazem algo com eles, e então eles retornam exatamente os mesmos dados. Então, por exemplo, disse o chefe, talvez tenhamos o 357 Nós colocamos. Judy, mande o chefe, então ele colocou no chefe. Vai ser preciso que ele vai enviá-lo para ele. Mas o que? O que é isso? Saída irá gerar a sequência numérica novamente. 357 para que pudéssemos enviá-lo para o chefe, multiplicá-lo por 10 e depois enviá-lo para os clientes ou algo assim. Portanto, a inação é perfeitamente boa como um filtro, pois fará alguma coisa. Levará os dados. Talvez ele mande para um servidor. Talvez ele faça um cálculo e defina outra variável. Mas a parte importante é que a saída deve ser a exata da entrada se estiver dentro. Se é uma ação, quero dizer que você pode mudar na ação para e fazê-lo sair de forma diferente, mas precisa haver uma saída com a qual possamos trabalhar. Então vamos rever alguns pequenos exemplos aqui e como você pode usar isso. Digamos que você tem uma empresa de investimento e você está trabalhando com, você sabe, ações que subiram e desceram. Então você tem essa lista de lucros e perdas em suas ações então talvez o 1º 1 Talvez eles estejam todos em dólares. Você tem o primeiro 1 é um 10 positivo e, em seguida, talvez um 30 negativo e, em seguida, talvez um 11 positivo e, em seguida, negativo 15. Digamos que estes são apenas os números com os quais você está trabalhando. Então agora o que podemos fazer é construir um modelo para nos ajudar com isso. Então queremos pegar qualquer coisa que seja maior que zero. Então vamos pegar o maior que 01 aqui. E depois queremos enviar isso para os clientes. Queremos mostrar aos clientes que estamos indo bem, que estamos fazendo coisas muito boas aqui. Então, qualquer coisa maior que zero vamos enviar para os clientes e, em seguida, qualquer coisa menor que zero nós vamos enviar para o chefe como Então? Então vamos pegar isso, vamos mandá-lo para o chefe. E agora o que vamos fazer é pegar esses dados e colocá-los. Então, se colocarmos esses dados aqui, vai ser maior que zero. E o que vai sair são apenas os 10 e os 11 que serão aprovados nos clientes do Senado . Esses serão enviados para os clientes, e depois passará por uma saída. Não sobrou nada, o que pára ali mesmo, e então também passamos para menos de zero. E então enviamos isso para o chefe, assim e então isso é tudo o que vai ser. Aqui está negativo 30 e depois negativo 15. Então os clientes estão recebendo o que está indo bem, e nosso chefe está recebendo o que está indo mal. Talvez ele possa ajudar a corrigir a situação. E muitas vezes, tubos e filtros farão isso. Teremos essa arquitetura em que você sai e você meio que invade essas coisas separadas e talvez até mesmo os dados se juntem novamente, e ele continua funcionando. Talvez todos eles comecem suas próprias correntes ou algo assim. Mas o tubo e o filtro só nos permitem pegar os mesmos dados e jogá-los da maneira que quisermos. Por exemplo, novamente, apenas por causa da clareza. Isso vai fazer um pouco menos desde então, mas vamos dizer, em vez de enviar os clientes por algum motivo, nós só queremos enviar números ímpares aos clientes. Então pegamos os clientes do centro e movemos para cá e então subimos aqui e dizemos que só queremos usar números ímpares. E novamente, este é um exemplo estranho, mas isso funciona perfeitamente bem. O código funciona porque há pequenas caixas pretas. Desde que os números dele cheguem, não importa como você armou isso. Então agora ele vai pegar todos os números maiores que zero vai então só pegar as probabilidades. Então isso significa que só ficaremos com 10 aqui, e então enviará para os clientes. E novamente, você pode misturá-los de qualquer forma, forma ou forma. Mas isso é sobre toda a abordagem de tubulação e filtro. Um membro dos pontos-chave aqui é que a entrada deve corresponder à saída. Então, se você tem um conjunto de números e precisa sair como um conjunto de números, se você tem um conjunto de cordas que precisavam sair como um conjunto de cordas ou qualquer maneira que funcionasse com o mesmo tipo de tipos aqui e também, uh, mesmo se você usar uma ação, você também precisa produzir essa ação. Tudo precisa ser personalizável onde você pode arrastá-los e soltá-los em qualquer ordem que você quiser, e eles vão funcionar perfeitamente bem com esse pedido. 14. Padrão de servidor de 3: Então agora vamos falar sobre o padrão do servidor cliente. Isso também é, às vezes, referir-se novamente como o modelo de servidor cliente. Mas o padrão do servidor cliente é um padrão que todos nós já usamos antes, e muitos de vocês podem olhar para isso e dizer: “ Espere, Espere, isso é um padrão. Isso é algo que podemos aprender sobre isso soou como conhecimento comum. Mas sim, é um padrão. É uma forma de as coisas serem organizadas. Então, com o padrão do servidor cliente, o que temos é que temos um servidor central. Então, por exemplo, vamos manter com um esquema de cores desta pequena imagem à direita aqui. Então temos um servidor bem aqui, e então temos clientes que contatam o servidor para obter informações, então temos pequenos clientes aqui e ali. Então, vamos novamente, vamos com o esquema de cores aqui. Então temos clientes cliente cliente cliente, e todos eles pediram informações ao servidor. O servidor, em seguida, distribui essas informações de volta para enfraquecer de volta para os clientes, de modo que as solicitações entram e o servidor distribui as solicitações de volta para fora, e é assim que basicamente a totalidade da Internet funciona. Se você for para Facebook Dot com. Entre em contato com o servidor do Facebook. Então isso, por exemplo, pode ser o Facebook. Você entra em contato com o servidor do Facebook, você pede a ele um monte de informações, e ele lhe dá cada pedaço de informação que ele lhe dá. Por exemplo, as atualizações mais recentes em sua linha de tempo. Ele fornece o HTML para que você possa carregar a página da Web. Ele lhe dá todas as imagens, diz onde tudo está, e na verdade envia esses dados. E toda vez que você atualiza uma página toda vez que você vai para uma nova página, uma nova solicitação é enviada para o servidor e uma nova resposta volta do servidor. E então o quê? por isso que este é um padrão é porque é uma maneira que todos nós podemos nos conectar a uma parte central de dados ou a um hub central de informação. Digamos que Ah, longe de uma boa maneira de explicar isso é em um servidor de jogo. Se, por exemplo, você estiver jogando jogos online como Call of Duty ou jogadores Desconhecidos campos de batalha ou quinzena, quinzena, todos os jogos que você está jogando exatamente na mesma hora no mesmo servidor, e É aqui que muitas pessoas entendem. Eles já ouviram o servidor de palavras antes. Então você tem todas essas pessoas e todas estão jogando o jogo exatamente ao mesmo tempo. Agora, o que o servidor está fazendo é calcular tudo. Está pegando uma informação, então está pegando a cada segundo, ou talvez a cada 10 vezes por segundo. Não sei quantas vezes ele atualiza o servidor. O seu cliente. Seu computador está enviando ao servidor sua localização, quão rápido se movendo, quais itens você tem. E o servidor está atualizando seu pequeno registro de dados com todas essas coisas. Ele não pega esses dados, e ele os envia para cada um dos clientes cada X número de milissegundos ou segundos. Desta forma, quando você está jogando o seu jogo, se alguém entra em. Então, por exemplo, digamos que este é o mapa no jogo. Você está bem aqui. Se alguém entrar na sua visão, você recebe uma mensagem que informa ao seu computador onde suas localizações ajudam, porque agora isso permite que seu computador renderize ou mostre essa outra pessoa em tempo real para você solicite que ela envie solicitar que ele envia e há 100 ou 200 pessoas fazendo isso exatamente ao mesmo tempo. E é isso que constrói o mapa e permite que todos corram por aí. Agora, se você já tiver um atraso no servidor, se houver algum atraso no jogo, isso é porque isso está demorando muito. Você pediu dados, e quando os dados voltam para você, essa pessoa já avançou muito. Então agora seu computador tenta exibi-los aqui. E então ele recebe outra mensagem de que não, a pessoa está realmente aqui em cima, então eles ficam na tela, e isso é uma queda comum de seus servidores. Diminuir é que os clientes não conseguem obter a informação. Mas o padrão do servidor cliente é um padrão bastante simples que novamente todos nós usamos. Ele só tem um servidor central, e você tem um monte de clientes que todos têm talvez software cliente que contata o servidor, que geralmente tem software servidor. Então, geralmente há dois tipos. Você tem o software do servidor, e então aqui em baixo você tem o software cliente em cada um destes, os dados de solicitação de Clement e nos dados são enviados de volta 15. Padrão de Master-Slave mestre: Nosso próximo padrão que queremos falar é algo conhecido como padrão escravo mestre . Então, como a descrição tipo de vai, há dois elementos para isso. Tanto o mestre, que geralmente é representado no topo de uma espécie de hierarquia e, em seguida, abaixo dela, um monte de escravos. Então nós temos nesta situação apenas criaremos três escravos diferentes aqui, então poderia haver três. Pode haver seis. Pode haver 1000 escravos diferentes. Não importa o que isso importa é que esse tipo de controle seja uni direcional, que significa que vamos dizer que essa cor aqui é os comandos. Os comandos em Lee vão para baixo. Então o mestre sempre diz aos escravos o que fazer, os escravos nunca, na verdade, menos. Eles não controlam o mestre. Eles não dizem dessa forma. Deve fazer alguma coisa. Um exemplo disso é para, hum com replicação de banco de dados. Digamos que este é o nosso banco de dados principal em nossos contatos principais do banco de dados. Digamos que nosso servidor, assim como nossos contatos do servidor. Um banco de dados vice-versa, e, em seguida, nosso servidor entrega os dados para fora para a web. Então, com o mestre, é sempre aquele que vai ser o mais atualizado. Vai trazer dados atualizados, enviar dados agora com os escravos que os escravos precisam para duplicar os dados do mestre . Então o mestre diz que pode ser à meia-noite ou 3 da manhã para atualizar. Então ele vai enviar um comando para um escravo aqui que diz escravo um. Comece copiando meus dados para seus dados. E assim vai levar. Ele vai pegar todas as novas mudanças, e ele vai se atualizar. E então o escravo vai ficar quieto. Não fará nada até que seja comandado novamente pelo mestre. Uh, unidades USB ou periféricos também usa. Então vamos dizer que temos um computador bem aqui e temos, você sabe, a CPU central e, em seguida, a RAM e etc, etc, etc, etc. Mas o que temos é que conectamos uma unidade USB aqui. A unidade USB está agindo como um escravo. Ele não diz o processo ou o que adiar o processador. Nesta situação, temos a taxa de processador aqui, nunca escuta esta unidade USB. Ele não escuta, você sabe, são comandos ou algo assim. O processador entra em contato com a unidade USB e diz, OK, fazer qualquer tarefa que nós da ciência. Digamos que estamos copiando dados dele. Diz: “ Ok, Ok, pegue seus dados e descarregue-os, também, são discos rígidos. Então, a unidade USB desligada carregada no disco rígido e, em seguida, o processador continua fazendo suas outras tarefas. E sempre que precisarmos entrar em contato com a unidade USB, ele faz exatamente isso. Ele entra em contato com ele, e então a U. S. B. Drive faz o que quer que ele diga. USB Drive nunca está tentando controlar qualquer outra coisa a menos que se torne um vírus. Nesse caso, o mestre escravo meio que quebra. Mas nessa situação com uma unidade USB normal, a unidade USB é um escravo nessa situação. E assim isto. Sabe, estávamos falando de hardware aqui, mas com software, podemos fazer isso também. Normalmente, fazemos isso com algo chamado controlador. Então, o controlador é sempre aquele que vai entrar em contato com todos os pequenos pedaços e dizer-lhes o que fazer dio. Então, com esse tipo de arquitetura, não temos comunicação entre nossas pequenas peças como aquela que nunca acontece. Então, com um controlador e um padrão de escravo mestre, o que temos é este controlador que dá ordens para fora. Então o controlador dá as ordens. Então temos mensagens que voltam para que as mensagens voltem para cima. E, em seguida, se os dados precisam ser colocados nesses outros que o controlador faz isso em si. Então basicamente é uma forma de isolar cada unidade aqui, cada módulo, isolando-o completamente um do outro para que possamos enfraquecer, trocá-los. Poderíamos marcá-los ou trocá-los e permitir que não tenhamos essa comunicação cruzada aqui, onde é muito difícil rastrear o fluxo de informações. Sabemos que se há informação ruim vindo aqui, deve estar vindo do controlador. O controlador deve ter um erro, ou deve haver uma cadeia, e isso nos permite uma espécie de backtrack. Isso muda um pouco melhor em vez de ter assim parece um pouco complicado, mas imagine se ele está comunicado. Você sabe, assim onde há apenas comunicações aqui e aqui do que este vem aqui embaixo . É impossível rastrear. Então, o que nós gostamos muitas vezes é que temos este controlador. Então o mestre escravo é um padrão muito importante. É usado bastante, e uma das pessoas nem percebe que está usando esse padrão. Mas é muito bom resolver um monte de problemas diferentes. 16. Padrão em camada: Nosso próximo padrão é o padrão em camadas. Então o padrão em camadas é basicamente apenas que é um monte de camadas diferentes e este suave para Roma. O que isso significa é que temos essas camadas de tecnologia, então as camadas de tecnologia só se comunicam dentro de suas próprias camadas. Então, por exemplo, esta é uma camada, e esta é uma camada, e esta é uma camada. Então o que não temos é que não temos comunicação cruzada. Não temos estes a tentar chamar informação de lá assim. O que temos é que temos a capacidade de comunicar para trás e para frente sobre a capacidade de comunicar para trás e para frente assim. E então esses Onley chamam dentro de suas respectivas camadas para que você possa ver que talvez uma ligeira desvantagem é se você tem algo aqui, ele pode ter que escorrer até outra camada. Você pode ter que ver alguns arquivos extras, certo? Um pequeno código extra. O que ele faz é classificar os dados para que se estamos procurando digamos que, uh, você sabe, você sabe, nós temos este é o nosso front-end. Este é o nosso back-end, e esta é a ligação entre os dois. Se temos um problema de volta, sabemos que estamos olhando para, você sabe, o programa dentro desta camada. E então isso ainda é bastante abstrato, então é realmente passar por um pouco de um exemplo bem aqui. Exemplo que eu quero rever é um padrão muito popular, em camadas, e você pode chamar este um modelo porque é uma coisa real que você pode implementar. Então ele é chamado de controlador de visualização modelo. Então, por exemplo, vamos colocar o controlador aqui e no lado direito vamos colocar a vista e o lado esquerdo. Vamos colocar o modelo de modo que o controlador de visualização modelo quebra os três aspectos diferentes aqui no lado direito. Como eu disse, temos a vista. A exibição é o que é mostrado para o usuário. A visão é o que podemos clicar, com o que podemos interagir. Então, nesta situação, digamos que temos uma página de perfil, então você sabe que há a foto do perfil, e então temos um pequeno formulário aqui para atualizar o perfil. Então nós temos ah, caixa uma caixa e, em seguida, a capacidade de realmente enviar essa caixa. E talvez estejamos mudando o nome aqui. Então isso é o que vamos estar tentando mudar o nome e o e-mail agora com o controlador de visualização modelo. O que temos no lado esquerdo é o modelo. Então este é o banco de dados. Este é o nosso banco de dados que tem o usuário aqui. Então ele vai ter a linha para o usuário e, em seguida, seu nome e endereço de e-mail. Então temos o nome de usuário e o endereço de e-mail ali mesmo. E, você sabe, ele tem um monte desses. Um monte de nome de usuário e-mail, nome de usuário , e-mail , etc, etc. Este é o modelo. Esta é a própria entidade real. Então, no lado esquerdo, temos o modelo, a entidade. Muitas vezes, é o banco de dados onde o tipo de dados é realmente armazenado. Agora, nós não queremos ter essa comunicação cruzada é essa habilidade para a visão falar com a modelo? Então o que fazemos é criar algo no meio chamado controlador. Então, no meio, o que temos é que temos o controlador e o controlador lida com toda a comunicação . Assim, o modelo entrará em contato com o controlador e o Troller Cullen entrará em contato com a vista e vice-versa. A exibição contata um controlador e o controlador entra em contato com o modelo. Então, por exemplo, clicamos no botão Enviar aqui. Os dados que atualizamos vão para o controlador. O controlador não vai ter alguma função como talvez ele vai ser uma função chamada usuário de atualização. E, em seguida, com essa função, ele vai então chamar para baixo para o modelo. O modelo está indo para pegar toda a informação que foi colocada aqui e ele vai atualizar o usuário. O que é que isto faz? O que isso nos ajuda a realizar? Ajuda-nos a descobrir onde estão os problemas. Temos esta camada de base de dados à esquerda, e temos esta camada de controlador no meio. E então temos essa camada de visão à direita. Então agora somos capazes de descobrir problemas. Temos o front-end. Este é o script Java no HTML. Então, Então, o tipo de visão das coisas. E se algo está confuso aqui, basta olhar para o HTML. Nós olhamos para o próprio site. Se tivermos um problema com os dados que estão sendo inseridos aqui, e ele não está chegando ao modelo. O que sabemos há um problema com o controlador. Então nós olhamos na classe controlador. Nós olhamos para a principal coisa que está realmente controlando ambos os lados, e então se o banco de dados está confuso, se temos que está chegando, sabemos que o controlador está fazendo o certo. Mas alguns, por algum motivo, o modelo não está sendo atualizado corretamente. O que sabemos para ir olhar para as bases de dados para olhar para o meu SQL, os diferentes tipos de maneiras dos bancos de dados armazenar coisas. Permite-nos esta camada. Ele nos permite essa capacidade de classificar e também construir diferentes elementos. Podemos ter front e desenvolvedores aqui poderíamos ter desenvolvedores mid-end. Aqui. Voltamos aos desenvolvedores aqui. Normalmente essas duas classes são cobertas por volta em desenvolvedores, mas você também pode ter um pouco de sobreposição onde os desenvolvedores front-end sabem um pouco aqui também. No geral, porém, o padrão em camadas é usado bastante para classificar nossos programas, para separá-los para que eles possam ser facilmente mantidos para que não haja um monte de código de espaguete e para que ele faz sentido para todos os envolvidos 17. Padrão de engenharia de software: Então faça tudo isso. Estamos tentando criar o processo de arquitetura de software, o processo pelo qual podemos criar uma arquitetura para um problema para um programa que estamos tentando projetar. Agora, esta é uma tarefa muito difícil e que estava muito longe no mundo criativo aqui. O que eu quero dizer com isso é que não vai haver um definido x y Z Primeiro passo segundo passo. Terceiro passo para este processo, vamos ter que ser criativos. Vamos pensar no nosso problema. Vamos pensar em outros problemas que foram concluídos, e eles meio que agarram a isso e projetaram uma solução única para o que estamos tentando fazer . Então, nesse sentido, em vez de ter um processo 123 nós meio que temos uma lista de objetivos que estamos tentando alcançar com nossa arquitetura, e isso pode ficar tão profundo ou tão alto nível quanto queremos para que possamos fazer isso muito un em profundidade. E com isso quero dizer, é uma espécie de planta geral. Podemos obter muito em profundidade sobre como exatamente cada pedaço de dados vai ser comunicado. Geralmente com projetos maiores e corporações maiores. Você vai obter profundidade Maurin e com um tipo de corporações em movimento mais rápido ou startups da Marinha em movimento mais rápido . Não passamos tanto tempo aqui, que está tentando colocar o produto lá fora. E então nós decidimos essas coisas mais tarde, o que poderia ser, Ah, muito caro. Ou pode funcionar para o seu projeto, dependendo de como está tudo configurado. Mas de qualquer forma, o que estamos tentando fazer é tentar controlar como um programa é decomposto e como ele interage consigo mesmo e com o mundo exterior. Isto também é importante para o mundo exterior. Então estamos tentando descobrir como o programa vai fazer. São só pequenas conexões. E também como ele se comunica com os usuários? Como ele se comunica com outros sistemas de software? Como é que faz isso também? E estamos tentando descobrir como ele basicamente se incorpora ao mundo? E então como construímos isso também? Como estruturamos isso para que funcione corretamente e também estamos tentando modelar como o controle ou estamos tentando modelar a estrutura de controle do sistema e como ele se comportará . A estrutura de controle é uma espécie de todos os padrões que temos feito. Vamos ter uma estrutura de controle, que é tipo, você sabe, talvez isso ou nós vamos ter talvez aquele escravo aquele mestre escravo um onde temos algo assim nós vamos ter o cano no filtro estrutura de controle onde vamos continuar colocando dados e depois filtrando por uma linha? Ou talvez tenhamos algo assim onde temos esses subsistemas todos juntos. Vamos ter um tubo no filtro chegando. Vai para um mestre escravo. Os mestres escravos não vão para uma espécie de controlador de visão modelo, etc, etc. Então estamos pegando tudo isso e estamos tentando combiná-lo de uma maneira que funcione para nossa solução. E como eu disse, não há nenhum corte claro. Os problemas são a solução. Poderíamos ter uma equipe de engenheiros. Outra equipe de engenheiros e outra equipe de engenheiros todos tentam criar a melhor arquitetura para o nosso projeto. E todos eles vão ser completamente diferentes. Alguns deles podem ser completamente, completamente diferentes. Talvez esses caras pensem o que devemos usar um tubo e filtro. Esses caras são tipo: “ Não, “ Não, não, não, o mestre escravo. Além disso, este e este modela como o fazemos. Esses caras têm uma maneira completamente diferente de fazer isso, e essa é a importância da arquitetura basicamente. É isso? Algo que temos que projetar sozinhos. Temos que descobrir. É um processo criativo, é por isso que muitas pessoas ignoram. É difícil. É muito difícil de projetar. Bem, o próximo passo que temos que fazer é quebrar o projeto nos subsistemas e módulos. Se você pode apenas fazer este passo, você está em uma situação muito boa para sua arquitetura. Então o que eu quero dizer com isso é que nós temos as duas coisas: subsistir, hum, e o módulo e o subsistema é um sistema independente que detém valor independente. E o que quero dizer com isso é que você poderia pegar este sistema e você poderia conectá-lo em outro programa e ele funcionaria corretamente. Ou você pode até mesmo vender este sistema. Alguém pode realmente querer comprar o sistema porque ele tem algum tipo de valor independente Ah, . módulo, no entanto, é um componente de um subsistema que não pode funcionar como um autônomo ou se ele funciona como um autônomo. É muito inconsequente. Não há nada que ele realmente faça que seja revolucionário. Então, digamos que temos, por exemplo, por exemplo, um pequeno módulo que divide por 10, em seguida, adiciona 30 e, em seguida, multiplica por 62 algum pequeno módulo estranho aqui em baixo. E a razão pela qual estou usando o módulo é a causa. Pense sobre isso. Este é um é um pedaço de informação. Agora podemos desmaiar para isso e distribuí-lo e ele recebe um novo número. É que tem alguma importância para nós, e podemos combiná-lo e talvez uma maneira importante. Mas você acha que alguém acreditaria nisso? É muito específico, e também não realiza uma tarefa por si só. Não temos nenhuma tarefa. Talvez ele realize uma tarefa muito pequena em um grande sistema de tarefas, mas por si só não tem valor independente. Agora vamos dizer que temos um monte desses pequenos módulos de equação matemática, então temos um pequeno aqui um aqui, um aqui, um aqui, um aqui. Aqui temos todos esses pequenos módulos funcionando, e agora eles são todos comunicação cruzada, qualquer que seja a estrutura deste subsistema. E nós temos agora este subsistema construído e digamos que este subsistema calcula talvez nossos impostos. Então esse subsistema agora é bom o suficiente para que com todas essas equações matemáticas, então isso é tudo que você sabe, como vezes 10 você sabe, menos 62. E talvez isto calcule o nosso seguro de hipoteca, etc. Você sabe, todas essas equações malucas estão indo juntas aqui, e então finalmente mostra o quanto você deve em impostos. Então ele introduz sua talvez sua renda, talvez você sua renda ou algo assim, e então produz quanto você deve em impostos. É um módulo importante. Isso é algo que poderíamos realmente usar. Isso é algo que podemos vender a alguém que talvez eles não queiram gastar o tempo desenvolvendo. Isso tem um valor comercial. Tem um valor independente. É feito de um monte de componentes que não têm valor por si mesmos. Quero dizer, nós, o cálculo , você sabe, sua hipoteca de casa talvez tenha um pouco de valor, mas quando você coloca isso neste contexto gigante, chegamos à habilidade que podemos realmente, você sabe, chegar a um ponto de vendê-lo. E digamos que isso é apenas nossos impostos pessoais. Aqui temos exatamente a mesma coisa. Temos um monte de pequenos módulos aqui e você importa. E agora você tem talvez imposto comercial. E então você importa negócios, táxi para fora negócios portuários e agora e agora e vai ficar um pouco desleixado aqui, mas eu meio que quero dirigir este ponto para casa agora. O que temos é que realmente temos um tipo de subsistema de subsistemas. Então, neste caso, temos quase todo o nosso software. Ou talvez nosso software seja como uma coisa de finanças pessoais, então pode haver outros também. Mas temos esse outro sistema que poderíamos vender para as pessoas também. Então este poderia ser um subsistema inteiro, e cada um desses poderia ser talvez mais subsistemas novamente. Você pode projetar isso de qualquer maneira que você quiser, mas apenas uma espécie de tentar conduzir o componente de módulos de ponto home de um subsistema que não pode funcionar de standalone. Então, se há essas pequenas equações ou um offs que realmente não podem ser vendidos, então provavelmente vai ser um módulo. E então também o que temos é que temos o subsistema, que está naquele módulo quando eles são todos juntos e vendidos. E mesmo com esse pouco de pensamento e planejamento, agora temos uma maneira que poderíamos dividir. As equipas Howard trabalham. Teremos um trabalho em equipe no lado dos negócios. Vamos trabalhar em equipe no lado dos impostos pessoais. Vamos ter talvez um trabalho em equipe aqui, um trabalho em equipe neste, um trabalho em equipe neste. Talvez uma equipe trabalhe nesta seção e uma equipe trabalhe nessa seção e você pode ver que já estamos tendo a capacidade de dividir a tarefa e nos tornarmos mais eficientes. E finalmente, com o processo de arquitetura de software, temos que manter um monte de coisas em mente. E você pode ver que esta lista é muito, muito, muito difícil. Na verdade, é da Wikipédia, este site, se você não colocar isso para dar uma olhada no que esses links vão, mas eles são todos esses tipos de termos que queremos pensar. Talvez só queiramos pensar em cinco ou seis desses termos realmente, realmente em profundidade. Mas queremos ter certeza de que estamos pensando em coisas como, você sabe, isso é confiável? A confiabilidade desta arquitetura? Quão eficaz é resolver o nosso projeto? Quão durável é? Talvez aguentemos o teste do tempo. Será quebrado com mais dados? Talvez queiramos ver a capacidade de reprodução. Será fácil copiar novamente para outro problema? Talvez tenhamos abordado o mesmo problema uma e outra vez e outra vez. Então, talvez queiramos projetar uma solução que possa ser reproduzida várias vezes em diferentes partes. A vulnerabilidade. Quão seguro é? Vai ser hackable? Será algo que já tem um risco conhecido? Cada um destes consorte de colocar algumas novas questões que talvez nos permita voltar e refinar um pouco a nossa arquitetura também. Próxima seção, vamos tipo de saltar para a próxima camada de arquiteturas. Então talvez tenhamos projetado apenas um pouco de como nosso projeto funciona e temos um controle . Fluxo completo funciona e no próximo Agora vamos começar a saltar em apenas um pouco do design, indo um pouco mais em profundidade para tipo de hash fora esses módulos e essas partes diferentes e como eles devem interagir exceto 18. Processo de design de software 4-1: nosso próximo passo ao longo da jornada de engenharia de software será projetado design de software . Então, nós passamos por requisitos. Nós fizemos os requisitos, os requisitos naturalmente nas especificações, que são novamente apenas uma espécie de mais requisitos técnicos das especificações . Em seguida, passamos para a arquitetura. Temos uma espécie de idéia com as especificações de requisitos. Então, tentamos criar um grande plano de jogo. Como estão esses módulos gigantes? Como eles vão interagir uns com os outros? Como os subsistemas serão divididos. Mas através disso, nós realmente não falamos sobre coisas como, que código vamos usar? Que software de verdade vamos usar, que software de banco de dados vamos usar. E é aí que entra o próximo passo, e isso vai ser o design. Portanto, o design é um passo em que começamos a aplicar nosso plano e nossa ideia às soluções do mundo real. Então, o que eu quero dizer com Riel Rose Solutions é que nós começamos a chegar com como nós pegamos nossa arquitetura, nosso plano geral e como nós projetamos isso? Como criamos soluções diferentes para criar essa arquitetura? Então, se a nossa arquitetura, por exemplo, chamou para uma volta e servidor. Então vamos fazer como um servidor tipo de símbolo lá. E então nós temos na frente disso nós temos talvez algum tipo de classe controlador e, em seguida, talvez uma página web. Talvez seja assim que a nossa coisa é. Estamos fazendo um tipo de controlador de visão modelo de coisa. Então, que tecnologias vamos usar? O que está de volta vai ser Será que vai ser executado em um sistema operacional baseado em Talvez Lennox ? E a partir disso o nosso servidor vai estar executando algum banco de dados? Talvez algo como o meu SQL seja. Qual será o nosso meio? Vai ser Ah, vai ser o JavaScript? Será talvez no próprio servidor, talvez algo como PHP ou que é uma espécie de em ambos estes, que é por isso que geralmente é uma coisa do meio. Ele poderia estar na página da Web, mas ele realmente executar o comando do servidor. Então talvez seja uma classe de controlador PHP em nossa página web vai ser HTML. Vai ser um quadro? Talvez estejamos usando algo como, se você já ouviu falar dele, WordPress, que é esse tipo de estrutura? É como uma frente de dragão no criador ou mesmo, ah, companhia como Wicks. W I. X é uma empresa onde você pode tipo de arrastar e soltar e projetar suas soluções, mas ele meio que cobre tudo isso também. Então talvez seja uma ideia. Então você pode ver que nós meio que inventamos esse plano geral de como queríamos configurar as coisas, mesmo que seja mais complicado com, você sabe, ah, ah, um monte de caixas se movem de maneiras diferentes e e agora é hora de olhar para cada uma dessas caixas e determinar qual é a solução do mundo real que vai resolver isso agora novamente, assim como nos requisitos em que não queríamos ultrapassar nossos limites e acidentalmente entrar no projeto que o projeto tem uma limitação para. Não queremos entrar acidentalmente na implementação, que é o próximo passo aqui. Design não é codificação e codificação não é projetado, que significa que não estamos começando construindo a estrutura ou qualquer coisa do tipo. Tudo o que estamos tentando fazer é descobrir o que as soluções do mundo real existem. O que precisamos criar, que tecnologia vamos usar para criar isso. E que tipo de plano de jogo para fazer isso? Isso é design. Agora, é claro, você faz um pequeno código exploratório aqui e ali. Ver se uma idéia funciona ser como, sim, você sabe, essas três linhas de código aqui, eles fazem o que eu penso. Então vamos colocar isso em um projeto. Não há um limite rigoroso aqui, mas o que estamos dizendo é, não salte direto para o revestimento a partir deste passo. um limite rigoroso aqui, mas o que estamos dizendo é, Não é isso que o design é. O design está criando um plano mais detalhado da arquitetura. E também, sempre que falamos sobre design, também temos que entender que ele tem uma espécie de duplo significado aqui. Design é tanto a atividade como o produto. Então a atividade está trabalhando para projetar um software como onde você tem uma equipe de pessoas e todas elas estão trabalhando ativamente, você sabe, chegando com como esse software deve interagir. Então as pessoas aqui, como essas ofertas devem interagir. Agora, o produto também é o design. É o documento de design. E então é um substantivo, que significa que é o próprio documento. É o produto final, algo que você poderia lidar com isso em casa e eles entenderiam exatamente como seu software funciona. Então, quando falamos sobre projetos, podemos falar sobre, essas duas coisas estavam projetando o produto, e estamos criando um design para o produto. Próximo passo, vamos começar a ir para os estágios de design indo para as perguntas que precisamos perguntar em quais problemas precisamos resolver. 19. 4-2 etapas de design: vamos passar por um conjunto geral de etapas de design para software. Então, por que estou dizendo que, disse o General, é que esta não é uma solução de tamanho único. Pode haver outro tipo de conjunto de princípios de design na empresa A Usos versus Empresa B. No entanto, se esta é a sua introdução ao design, este é um bom começo, um bom lugar para começar sempre que você estiver pensando em design. Então, temos oito passos aqui, e esses passos podem ser tão detalhados ou não detalhados quanto você quiser. Uma espécie de. O que você coloca é o que você ganha quando você faz algo assim. Se você passar mais tempo aqui, você gastará menos tempo e implementação e revestimento. Então, depende muito do que você quer fazer. Porque muitas vezes você vai realmente encontrar bugs e problemas arquitetônicos e problemas de design dentro do projeto aqui que você não encontraria até que você já tenha revestido a coisa até que você já tenha gasto, você sabe, 400 horas de revestimento e então você percebe que você tem que voltar e refazer algo, então se você passar muito tempo aqui, você pode muitas vezes economizar muito tempo no futuro. Então nossos passos funcionam assim primeiro é dividirmos o problema maior em problemas menores . Se estamos projetando, por exemplo, Amazon se quisermos. Se temos essa idéia de uma empresa chamada Amazon e queremos desenvolver este site onde vai ser um comércio on-line e as pessoas podem, você sabe, você sabe, enviar seus produtos para nós e um monte de empresas e vir em yada, Yada, etc, vai haver muitos problemas dentro deles. Este é um problema que vai ter uma tonelada de problemas abrangentes. E a partir desses problemas abrangentes, vamos ter problemas menores e menores e menores até chegarmos a algo que é um pouco mais gerenciável. Se formos com um exemplo ligeiramente menor, embora, por exemplo, digamos aquele com o trabalho, que é criar um site, digamos que um de nossos problemas é o banco de dados a maneira de armazenar nossos dados em o back-end. E com isso, esse é o nosso problema. Esse vai ser o grande problema dividiu-o em um problema menor, que é como fazemos o banco de dados? O que fazemos para colocar o banco de dados funcionando? Então, nesta situação, nós agora dividi-lo em um problema de design de banco de dados. Agora precisamos entender cada um desses problemas. Então, por exemplo, se estamos fazendo isso, podemos fazer isso um por um. Ou podemos dividi-lo em um monte de pequenos problemas submarinos e, em seguida, passar para o passo dois. E assim que quebrarmos ainda mais, poderíamos passar para o passo três, etc. Eu só vou tipo de mira ou reunião de abordagem de cima para baixo nós vamos ter um problema pode ser um de muitos problemas, por exemplo, e então nós vamos apenas descer, passo a passo, sobre e mais assim. Então precisamos disso. Agora, entende esse problema? Qual é o propósito deste problema? Por que temos esse problema? O documento de requisitos pode vir a calhar aqui porque os documentos de requisitos devem estar nos dizendo o que estamos tentando resolver. E agora temos uma espécie de maneira que podemos voltar e olhar, talvez requisitos. Documento diz algo como, precisamos armazenar informações do usuário. Então, se precisarmos armazenar informações do usuário. Bem, é claro que precisamos de um banco de dados para isso. Talvez ele. Precisamos realizar transações. Se quisermos fazer transações, precisaremos de um banco de dados para isso. E podemos listar todas as diferentes partes deste problema informações do usuário, transações, imagens, etc., para se adequar ao nosso problema. E uma vez que entendemos tudo isso, agora temos uma idéia sobre qual banco de dados precisamos projetar. Portanto, agora precisamos identificar soluções potenciais. Que soluções existem para nos ajudar? Há algo chamado AWS Amazon Web Services. Temos que podemos construir. Nossos próprios servidores são talvez nosso próprio servidor. Poderíamos comprar espaço de servidor em outra empresa do país para comprá-lo em algum lugar . Nós criamos o nosso, mas depois enviamos para um lugar de compra. Poderíamos usar tecnologias diferentes, como um banco de dados SQL. Um normal resgatado fora do lugar, talvez um banco de dados sem SQL. São todas essas opções diferentes E é aqui que precisamos realmente abrir nossas mentes e chegar a tantas soluções para o problema quanto possível. Nós não queremos entrar com uma espécie de mentalidade de Ok, vamos trabalhar com a AWS, e vai ser isso e aquilo sem qualquer razão para isso. Talvez a empresa diga que talvez como a empresa de design ou o cliente diz que devemos usar oito de nós. Isso é bom. Isso é um requisito de que algo que constranja, não temos escolha sobre isso. Nesse caso, isso vai entrar em nossos documentos de design, apenas oito de nós. Mas se não temos essa restrição, se temos a possibilidade de chegar a soluções diferentes, então precisamos encontrar essa mini solução o mais possível para que tenhamos certeza de escolher a melhor . Porque se formos apenas visão de túnel nós mesmos e não nos concentrarmos ou se concentrarmos demais, teremos um problema onde uma solução melhor poderia estar disponível. O próximo passo é descrever abstrações de soluções. Então, o que são a solução? Abstração? Solução? Abstrações são coisas como documentos de design que não são técnicos. Então ele diz que temos um modelo X aqui que contatos, modelo, modelo, por que e o que este fluxo de controle. Isso remonta ao modelo W. E isso contata isso. É uma espécie de esta maneira de usar gráficos e modelos como este aqui mesmo para chegar a um plano geral para o nosso software. Então isso é uma abstração. Isto é como nós estávamos indo para configurar o nosso banco de dados para que você possa ver que temos ah usuários coluna um posts principais ou usuários tabela principal post funcionários post, post admin post. E então todos estes e todos eles se conectam dessas maneiras. Agora, isso é um pouco mais longe no lado técnico do que talvez algumas abstrações possam ir, mas tudo bem. Nós temos você sabe, em vez de, você sabe, colocar tudo isso aqui em baixo, nós poderíamos apenas chegar com os nomes das tabelas. Isso seria uma boa abstração para que possamos descrever como vamos armazenar os dados . Mas você pode ver o que esta mesa bem aqui. Temos uma ideia muito boa sobre como o banco de dados vai funcionar. Então nós meio que o escolhemos. Vamos usar o meu banco de dados SQL nesta situação, e o próximo passo é o tipo de abstrações está chegando com esses modelos. Talvez seja assim que o controlador funciona. E aquele gráfico que acabei de mostrar que o gráfico é talvez este módulo aqui. E então talvez aqui embaixo é o, hum talvez como os dados vão entrar e sair as coisas organizacionais, e assim podemos meio que dividir isso em outros. E basicamente, o que fazemos é repetir esse processo uma e outra vez até irmos com todos esses problemas. Memorize disse que tínhamos, como tivemos. Talvez esses problemas que se dividiram nesses problemas, etc. Então vamos tentar abstrair tudo até terminarmos basicamente. Até termos esse nível realmente, realmente de cima para baixo sobre todos os diferentes componentes e idéias sobre como tudo funciona em conjunto até que essas abstrações sejam feitas. Então, uma vez que fazemos tudo isso, uma vez que todas essas abstrações são meio que descobertas aqui. Vamos então passar para os próximos passos aqui. Então muitas vezes queremos um loop aqui até descobrirmos tudo e então podemos passar para o próximo passo e os próximos passos um pouco mais avançados. Próximo. Muitas pessoas pulam só porque é meio difícil de fazer e você precisa ter a experiência para fazê-lo, mas isso vai ser basicamente codificar a coisa sem cobrir a coisa. Lembre-se, dissemos que design não é código. Não é o código que é importante. No entanto, isso não significa que não podemos determinar como tudo vai interagir. Então o que eu estou dizendo com este passo é que nós estamos realmente indo para criar os componentes como este, e então com cada um desses componentes iria vir acima com talvez ele vai usar esta classe e esta classe vai ter este método, este método, este método. Você sabe, este método fala para ouvir este método fala. Ouvir este método fala aqui e depois vamos olhar ainda mais longe. Qual é o método de transferência? Talvez esteja se transferindo para a matriz. E como vamos classificar essa matriz? Talvez estejamos usando um algoritmo chamado T. Talvez estejamos usando um algoritmo chamado Merge Sort. Então nós entramos em, como, realmente, muito, detalhes gritty sobre isso. Começamos a ir pedaço por pedaço e chegar com uma espécie de árvore de classe gigante, que poderia ser muito, muito, muito grande se você planeja a coisa toda. Mas no final, nós realmente temos esse grande documento onde todos podem ir e olhar para ele e entender como o programa funciona sem nunca girar um servidor ou desenvolvimento. Eles só vêem todo o código lá, este processo. É importante. Mas eu vou. Eu meio que vou confessar com isso, e nós vamos falar sobre isso mais tarde. No curso. É muito, muito tedioso. E há um monte de sobrecarga e na maioria das vezes. Uma vez que você desenha isso, as coisas mudam e então não é atualizado, então fica desatualizado e basicamente inútil. Então, mesmo que estes sejam passos importantes no processo de design, modelos mais novos hoje em dia meio que renunciam a isso para desenvolver soluções mais rápidas e rápidas. Em, nós meio que jogamos fora a documentação apenas um pouco porque nós não precisamos de livros. Nós não precisamos de livros sobre documentação do nosso software empilhados alto e, em seguida, não temos realmente software que possamos mostrar para ele. Nós só temos esse design muito, muito bom, então há um equilíbrio lá, e é aqui que começamos a falar sobre a metodologia ágil mais tarde, mas só queremos jogar isso. Há se você está indo para este curso, você sabe, palestra por palestra. Não pense que você precisa fazer isso 100% porque muitas vezes não é realista, e as pessoas meio que jogam fora. No entanto, entender talvez os princípios fundamentais ajudem você quando você chega a outra parte, porque agora você entende o que você está desistindo para obter essa velocidade, etc. Mas essas são as etapas do design. Como eu disse, isso muda o tempo todo. Sua empresa pode ter outro conjunto, mas este é um bom conjunto para meio que levá-lo a partir desse nível de idéia e realmente começar a dividi-lo para obter uma boa idéia quase em um nível de código sobre como seu programa deve funcionar. 20. Modularity 4-3: Então falamos sobre um bom design de software. O que estamos tentando chegar a essa idéia de modularidade. Então modularidade é essa idéia de pegar nosso programa e dividi-lo em módulos diferentes . Lembre-se, falamos sobre subsistemas e módulos. É a mesma terminologia aqui, mas com modularidade, temos um conjunto de objetivos em mente. Não queremos apenas separá-lo, Willy Nilly. Queremos separá-lo de uma forma inteligente. E com isso o que estamos tentando fazer é atingir os objetivos principais. Então, com o nosso módulo, digamos que temos um pedaço de código aqui com o nosso módulo. Queremos que este módulo seja independente, e essa é a parte de acoplamento. Independente significa que todas as suas ações e dados sobre Lee se afetam. Não temos um módulo aqui controlando-o em um módulo aqui controlando-o. E talvez esteja controlando um módulo aqui. E este está controlando isso, etcetera, etc. Então você entra em um problema realmente grande de um erro aqui, pode realmente se representar aqui em cima. Ou, na verdade, ele poderia ir e representar a si mesmo todo o caminho até aqui. Você tem um problema quando eles não são independentes, então esse é um dos nossos objetivos. E é isso que o acoplamento é. Teremos uma palestra inteira sobre isso. E então coesão é quão singular existe um módulo? Como o que eu quero dizer com singular é, são seus objetivos desenhados singularmente? Se os objetivos ar singularmente projetado enfraquecer, pegue esse módulo, podemos removê-lo do programa e colocá-lo em outro programa. Se tivéssemos uma página da Web e esta página da Web tivesse este controlador nela, e este controlador controlasse tudo, quero dizer, quero dizer,está a falar com um monte de outros controladores. Então talvez ele tenha realmente um bom acoplamento no sentido de que, apesar de estar controlando tudo isso, nada o controla, e seus dados são muito encapsulados dentro de si mesmo. Mas o problema aqui é que ele está muito, muito bem sintonizado com exatamente esse problema, que significa que se alguma vez tentarmos tirar isso ou colocar uma nova peça, não funcionaria. Isso é muito, muito específico para esse problema exato, então ele não atende a um objetivo de design singular. Está fazendo tudo. Não há objetivo. Quero dizer, você poderia, você sabe, dizer site de controle. Esse poderia ser o seu objetivo, mas esse é um objetivo muito amplo, e não é algo que é muito singularmente projetado, e é isso que falamos sobre coesão. Então, com modularidade, estamos tentando obter esses dois aspectos. Estamos tentando obter os dois o melhor possível. Estamos tentando torná-lo muito independente e, em seguida, muito singularmente projetado. Assim, os objetivos da modularidade, os objetivos da modularidade são os seguintes. Há um conjunto diferente. Eu, se você olhar para os objetivos, vai ser conjuntos diferentes. Para todas as pessoas que falam sobre isso, no entanto, este é um conjunto que eu gosto de sair. O primeiro e mais importante objetivo da modularidade é a abstração. É basicamente pegar nosso módulo e colocar em uma caixa preta para remover a complexidade. Estamos falando sobre isso na informação, escondendo um pouco, mas abstração é muito importante porque nos permite projetar ideias de nível mais alto. Se tivéssemos que, por exemplo, trabalhar em linguagem de máquinas, o que significa que estamos, você sabe, controlando uns e zeros o tempo todo. Não queremos fazer nada. Seria muito complexo, mas alguém abstraiu isso para uma linguagem assembly, então isso é assembly, e então alguém realmente abstraiu essa linguagem assembly até provavelmente outra e, em seguida, até o nosso linguagem, como Java para que possamos usar Java com seu. É relativamente fácil de usar funções que, em seguida, descomprim-lo para baixo em qualquer linguagem que vai para a linguagem assembly que vai para linguagem máquina. linguagem da máquina controla o carneiro, etc. Então, quando estamos falando de abstração, estamos falando da capacidade de pegar essas idéias complexas e lentamente trazê-las para remover essa cidade complexa para que possamos construir mais e mais programas avançados, decompor a habilidade em compor. Significa que podemos desmontar a coisa e remontá-la. Isso ajuda na depuração. Isso ajuda com a adição de novos recursos. Isso ajuda basicamente, tudo o que tem a ver com manutenção é que queremos ser capazes de abrir este programa, pegar partes de desmontar tudo e depois colocá-lo juntos novamente. E isso realmente ajuda quando você tem os dois. E a linha é porque você pode tirar este controlador e ele não quebra todo o site. Você pode realmente, você sabe, tipo de hot swap um novo controlador e talvez um que faz as coisas um pouco diferente de forma mais eficiente. Torna-se muito fácil de manter após esse módulo, entender a capacidade ou apenas entender a capacidade se você quiser mantê-los todos. É uma palavra aqui. O que entender habilidade significa é que eu poderia pular em um módulo e entender instantaneamente o que ele está falando com este aqui. É muito, muito profundo. Isto pode ser talvez, digamos, 35.000 linhas de código. Você acha que seria capaz de entender o que este módulo está fazendo imediatamente? Provavelmente não. Mas digamos que temos este pequeno módulo aqui, e tudo o que ele faz é talvez fazer atualizações no banco de dados. Então tudo que ele faz é atualizar banco de dados, e talvez esse seja seu nome. E há, você sabe, funções como atualizar, inteiro, atualizar , , encadear a senha de atualização do usuário. Nós investigamos isso. Dizemos que há um problema com as atualizações dentro do nosso banco de dados. Podemos facilmente ir bem, vamos verificar a atualização, banco de dados, pasta ou o arquivo, e é muito fácil. Muito rápido de entender. A próxima é a continuidade. Continuidade é um pouco de uma idéia onde você tem, digamos que você está usando Constance Constance é de uma maneira muito boa de colocar isso. Temos X igual a três. Então, em vez de ter em cada um desses aspectos, uma variável de X é igual a três X igual a três X igual a três X igual a três X igual a três X igual a três X igual a três. Imagine se agora, em nossa situação, X for igual a quatro. Bem, agora temos que passar por cada um desses e mudá-los para quatro, que vai ser ou nós vamos perder um e então nós vamos ter erros estranhos começar a aparecer. Ia ficar difícil de manter. Mas se tivéssemos uma pasta constante, tínhamos um arquivo constante aqui com aquele dito, X é igual a quatro. Bem, então tudo isso poderia apenas fazer referência ao arquivo da Constance e isso está ficando um pouco confuso agora. Mas eu estou tentando, você sabe, trazer para casa esse ponto bem ali. É que se tivéssemos aquela pasta constante lá em cima, então tudo o que temos que fazer é mudá-la em um só lugar, e ela será contínua ao longo de todo o nosso projeto. Então, ter isso em mente também é muito importante e, finalmente, proteger a capacidade da maneira que podemos proteger os dados é se nós mantê-los muito, muito tipo de desbloqueio em arquivos específicos, nós não temos, você sabe, 85 arquivos diferentes contatam no banco de dados. Temos um único controlador ou um único conjunto de controladores que o fazem. Isso não só nos ajuda com consequências não intencionais, mas também nos ajuda contra hacks e outras coisas. Porque se tivermos 86 pontos de entrada diferentes em nosso banco de dados, tudo o que tem que acontecer é que um deles tem que falhar antes que alguém salte. Então, ter isso sob controle é muito, muito importante. E modularidade ajuda você a manter e obter uma segurança mais forte. Então essa é a introdução da modularidade. Nas próximas palestras, falaremos sobre ocultação de informações e encapsulamento de dados, que são outros inquilinos chave da modularidade. 21. Hidding e elaboração de dados: Então, o próximo tipo de etapas de modularidade ou os próximos locatários de modularidade, nossas informações escondendo encapsulamento de dados finais. E ambos são realmente apenas formas de abstração e importância da abstração. Então o 1º 1 está escondendo informações, e isto é, você esconde a complexidade em uma caixa preta. Mas quando estamos falando de abstração e estamos falando sobre como você pode pegá-la da linguagem de máquina e trazê-la até o fim para que possamos fazer coisas de nível mais alto, bem, bem, isso é o que a informação oculta faz. Esconde a complexidade em uma caixa preta. Cada uma delas é uma caixa preta que esconde a complexidade. Quando você escreve coisas para linguagem assembly, você está usando coisas que esta linguagem aqui em baixo, a linguagem máquina expôs alguns olhos AP. Alguns comandam algumas funções. Você está usando esse código para criar isso e, em seguida, com linguagem assembly, você cria um novo conjunto de funções, controles e comandos, que este próximo idioma trará. Uma vez que suas próximas linguagens sejam feitas, você cria outro conjunto de códigos e comandos e, em seguida, Java. Em cima disso vai começar a chamar esses códigos e demandas que vão chamar esses códigos e comandos que porque aqueles que vão fazer coisas como mover a memória ao redor. Então, com isso aqui, o que estamos tentando fazer com esconder informações é esconder essa complexidade em uma caixa preta. Poderíamos fazer isso com coisas chamadas funções como classes de biblioteca macro, método thes air, todos apenas os termos técnicos que usamos sempre que estamos programando. Mas digamos que temos uma caixa preta adequada aqui e outra caixa preta adequada aqui e o que eles são é um dispositivo de criptografia, criptografia e então um dispositivo de descriptografia. Então, se, por exemplo, colocarmos 35 aqui e sair com eu não sei, não por que 62? Então essa é a saída. E então agora tomamos o porquê 62 colocá-lo no er descriptografado. E sai como 35. Precisamos entender como ele está criptografando e descriptografando para ser capaz de usar essas duas caixas para ser capaz de usar esses dois programas? Não, não em tudo. Tudo o que precisamos saber é, o que é? Entrada. E estava indo para a saída? E estamos completamente bem em usá-lo para todos os seus propósitos. Os internos não são necessários para serem conhecidos, e isso é muito importante. Isso é algo que é muito útil. Sempre que estamos projetando programas, especialmente com digamos, estamos projetando um programa para um, digamos, digamos, um fabricante de automóveis. Nós temos todo esse código que talvez auto gera código em segundo plano diria que é , ah, ah, carro auto-dirigindo alguma coisa. Mas não somos pessoas de carros. Não entendemos como os carros devem ser feitos. Não entendemos como tudo deve ser programado. Então o que fazemos é programar um conjunto de botões, um conjunto de tabelas e interruptores e outras coisas, como um pequeno painel de controle aqui e com esta programação. Em seguida, abstraímos toda a gritty nitty da programação real. Os quatro loops, o while loop as funções das classes de bibliotecas de Macron. Abstraímos tudo isso, e permitimos que um técnico aperte os botões e insira valores, e então nosso código fará o resto. Então temos dado o controle do engenheiro de automóveis Mawr. Demos a eles o poder de usar nosso código com suas coisas, e essa é a importância de ocultar informações, pois permite que coisas cada vez mais complexas sejam construídas. Ele permite que você tipo de criar uma base e, em seguida, construir sobre essa base e continuar criando coisas mais fortes e fortes ao longo do tempo. E é assim que os programas estão ficando mais complexos ao longo do tempo é que estamos lentamente ficando melhores nesta abstração e indo mais e mais além de informação. Acho que é a ideia de esconder a complexidade numa caixa preta. O próximo é algo chamado de encapsulamento de dados, e isso você vai notar que eles são realmente muito próximos. Esta é uma espécie de informação escondida, enquanto esta poderia ser conhecida como ocultação de dados, então eles têm um relacionamento. Mas este é tudo sobre esconder os detalhes da implementação do usuário e Onley fornecendo um conjunto de ferramentas para manipular os dados. O que queremos dizer com isso é, digamos que temos uma classe aqui e uma de suas variáveis é, digamos, digamos que temos uma classe aqui e uma de suas variáveis é, digamos, dados de transação. Então, talvez a quantidade de dinheiro, então colocamos a transação aqui. Agora, por que precisaríamos colocar uma função get e a função set? Por que não temos o que está nesta classe se chama banca? Por que não permitimos que esse programa aqui chame algo como transação bancária é igual a 50. Por que não permitimos isso? Por quê? Por que não permitimos que isso faça uma chamada direta para a transação? Bem, este tipo de quebra a ideia de encapsulamento de dados. Se fizermos isso, então, de repente, nossos dados podem ser manipulados de qualquer forma, forma ou forma, e não temos nenhum controle sobre eles. Não podemos impedir o usuário de colocar dados inválidos e estragar não só nossos algoritmos, mas talvez toda a nossa base de dados. Então, com o encapsulamento de dados, o que fazemos é criar esses getters e centros. Então, se aqui quisermos saber qual é a transação. Ele chama o git, então ele chamaria o git, e então a função get iria retornar o valor Esta função get poderia ser muito importante , porque talvez ele tenha uma camada de autenticação nele. Talvez tenha uma camada de autenticação com isso. Isso significa que uma senha precisaria ser inserida antes que essa classe forneça dados. E isso é muito importante no mundo bancário. Você não quer apenas que as pessoas sejam capazes de programar coisas e agarrar diretamente do servidor. Qualquer coisa que eles quiserem. Então, pegue-a ajuda a proteger nisso. E então um centro é muitas vezes mais importante. O centro nos impedirá de fazer certas coisas. Então vamos chamar uma função para definir. Talvez digamos que queremos definir a transação para 50 negativos. Bem, o centro vai ter apenas uma simples declaração pouco se aqui se você souber menos zero retorno. Então, se menos que zero retornar, eu não sei, erro algo realmente, muito simples. E este é um ar de retorno menos simples, menos que zero. E por que isso é importante? Bem, estamos fazendo transações e vemos continuar cobrando negativamente as pessoas. 50 dólares. Bem, vamos começar a ganhar dinheiro do nosso jeito, e isso é um problema. Nós nunca queremos que uma transação vá abaixo de qualquer dinheiro porque em vez de cobrar nossa conta, nós estamos apenas pegando dinheiro de pessoas. Então, um centro simples adicionaria outra camada de segurança lá também e também protegeria a integridade do nosso banco no sentido de que ele pode ter mais verificações aqui. E não podíamos depositar, digamos, um $1.000.000.000 por acidente, ou pode haver uma extremidade superior que potencialmente o encaminhe para um gerente ou algo assim. Mas, no geral, a idéia de encapsulamento de dados é uma espécie de proteger os dados, tornando-os. Então nós só expomos esse tipo de conjunto de ferramentas para manipular os dados em vez de apenas permitir que os dados sejam acessados e alterados de qualquer maneira, forma ou forma que quisermos. E assim, com um bom design de software, pensamos sobre esse encapsulamento de dados também. Pensamos no porquê. Por que estamos deixando as pessoas pegarem esses dados? Por que não fazemos um getter em uma função central? Por que não o protegemos de alguma forma, ou criamos uma classe inteira que lida com esse tipo de coisa para proteger a integridade do nosso banco de dados? 22. Introdução em acoplamento 4-5: Na última palestra, introduzimos essa ideia de acoplamento. E assim com acoplamento, o que estamos falando é a força das conexões entre módulos e subsistemas. Agora, com o termo “força “, temos essa ideia de uma conotação positiva. No entanto, com o acoplamento, não queremos essa força. Queremos uma verdadeira fraqueza entre modelos. Não queremos que modelos, módulos e subsistemas sejam bem acoplados. E então quando estamos falando sobre acoplamento, queremos dizer quase como se eles dependessem um do outro. Então, por exemplo, se tivéssemos um monte inteiro, um pequeno conjunto de módulos e subsistemas aqui, digamos que há apenas esse tipo de ligação e cadeia, assim e, você sabe, como complexo ou não complexo o seu programa é, podemos ter uma seção que está firmemente acoplada, e quando uma seção está firmemente acoplada, isso significa que se fizermos uma mudança aqui, por exemplo, e quando uma seção está firmemente acoplada, isso significa que se fizermos uma mudança aqui, por exemplo, vai então ter que ir para este arquivo e fazer uma alteração. Vá para este arquivo e eles podem mudar. Vá para este arquivo e faça uma alteração. Vá para este arquivo e eles podem mudar etcetera etcetera até que tenhamos basicamente tudo mudado para que isso faça a mudança aqui realmente funcionar. Isso tem um monte de desvantagens. O 1º 1 é apenas o tempo. Vai levar tempo para descobrir o que exatamente está acoplado com isso Normalmente fazer julgamento e ar. Nós executamos o programa, diz. Espero que tenha havido uma pausa aqui. Então vamos mudá-lo lá, executar o programa novamente. Houve uma pausa aqui. Vá mudá-lo lá se você tiver documentação melhor, talvez um pouco mais rápido, mas muitas vezes você pode. Tenho que ir ao intervalo e consertar. A próxima parte é, é que ele só vai levar basicamente a capacidade de manter o programa e diminuí-lo . Porque agora, quando fizermos essa mudança, talvez tenhamos feito todas essas mudanças. Mas esquecemos deste caso aqui em cima. E este caso Onley opera, você sabe, talvez uma vez por mês, talvez seja algum código estranho que é como, ah, ah, coisa de servidor que opera uma vez por mês, e nós esquecemos de mudá-lo aqui . Então nós passamos por todos os testes e coisas, e está parecendo ótimo e então em um mês nós temos um inseto gigante que aparece. Não sabemos de onde vem. Bem, é porque vocês estão bem unidos. É por causa dessa mudança que isso acontece. E é ainda pior quando chegamos a algo assim onde é realmente aqui embaixo é onde esse problema está porque agora temos que pensar, o que mudamos? Talvez só estejamos olhando para esses dois arquivos ou como se não mudássemos muito aqui. Oh, na verdade foi esta grande mudança aqui em cima que causou este ar em cascata tão bem acoplado . Programas geralmente são ruins. Você não vai realmente chegar ao ponto de nenhum acoplamento, mas você quer tentar soltá-lo o mais possível. Então, com o acoplamento apertado, temos a idéia de variáveis compartilhadas e informações de controle. Então tudo isso aqui é a idéia de informações de controle. Então nós temos esses métodos e classes que estão todos falando diretamente com outros módulos são todos controlando diretamente outros módulos, então mudanças em um vai exigir mudanças em todos os outros. E então se tivermos a idéia de variáveis compartilhadas, é onde temos esse tipo de lista gigante de variáveis, e cada programa na parte inferior está usando essas variáveis. Então, se fizermos uma mudança aqui, há muitas vezes nós vamos realmente ter que fazer alterações em todos os arquivos inferiores também. E essa estrutura pode realmente ser benéfica em algumas situações que podem ajudar a reduzir outras áreas de problemas. Mas também pode criar problemas. É por isso que toda essa idéia de design temos esse tipo de equilíbrio que temos que desenhar. Não há nada que seja perfeito. Então tivemos que descobrir o que é o mais perfeito que podemos obtê-lo. Qual é o mais otimizado que podemos obtê-lo, e essa é a direção que temos que seguir. E então a descentralização do estado cria deve ser um ver seus cria acoplamento solto. Então o que queremos dizer com isso é descentralização do estado é onde temos um tipo de pequenos segmentos aqui. Talvez esses dois estejam juntos, mas temos outra seção onde esses dois estão juntos e, você sabe , etc, etc. Mas, no geral, não temos todo o programa sendo acoplado em, você sabe, todos os sentidos. Temos quase esses pequenos estados fazendo suas próprias coisas com pouca comunicação entre o acontecimento. E isso nos ajuda novamente com toda a depuração e coisas assim mais tarde. Então, na próxima palestra, o que estamos realmente falando é sobre nós vamos estar falando sobre os três níveis de acoplamento que vai ser acoplamento apertado, acoplamento médio e, em seguida, acoplamento solto. E há pequenas categorias em cada um deles casal de conteúdo em controle externo comum , estrutura de dados, mensagem de dados e, em seguida, nenhum. E novamente, como eu estava dizendo antes, nenhum é muito impraticável. Provavelmente não há quase nenhum aplicativo que não usará acoplamento. Mas queremos ser capazes de passar por todas essas etapas para que possamos olhar para um programa e entender como, acoplado a este programa, quão bem tricotado é e, você sabe, isso é bom ou ruim? 23. Acoplamento importante: Vamos falar sobre nosso primeiro tipo de classificação de acoplamento, e esse será o pior cenário de acoplamento. E essa é a idéia de acoplamento apertado. Então, um acoplamento apertado temos um monte de módulos que são tricotados juntos. Um bem unido com isso significa que se fizermos uma mudança em um módulo, vamos ter que fazer uma mudança em um monte de outros módulos para torná-lo para que o programa não quebrar isso poderia ser uma espécie de dividido em este tipo de sub , estas calças comuns de ar, de tipos de acoplamento apertado e que vai ser em conteúdo, comum e, em seguida, externo. Então nós vamos fazer um tipo de tarefas um por um e você verá que eles são um erro muito fácil cometer. Mas eles podem causar problemas muito grandes. O 1º 1 é com acoplamento de conteúdo. Então o que isso é é quando um módulo modifica sobre mentiras sobre o funcionamento interno de outro módulo. Neste cenário, temos o módulo A e, em seguida, o módulo B e o módulo A está pegando diretamente do Módulo B. Ele está pegando a taxa de dados fora do Módulo B e usá-lo para suas próprias coisas. Digamos, por exemplo, que o módulo ser os dados em questão é algum tipo de distância. Então é algum tipo de distância. Digamos que em B, é representado como medidores. Uma coisa típica que pode acontecer. Talvez peguemos de um P.I. Talvez seja a forma como programamos. Mas os dados aqui em B são metros. Bem, o módulo A quer converter isso em Miles, então vai levá-lo de metros e tentar convertê-lo em milhas. Então é tudo o que faz. É agarra diretamente do ser. Ele envia um algoritmo de conversão não e, em seguida, faz o que ele precisa fazer com ele. Agora você pode ver o problema aqui? O problema é que, se alguém entra e quer modificar ser, digamos que também temos outro aqui que está fazendo a mesma coisa. Agarrar dados de batida pode estar convertendo-os de alguma outra forma, mas é assumindo que B vai permanecer o mesmo. E esse é o problema. Aqui está a suposição de que B nunca mudará. Bem, como eu disse, outro programador vem aqui para ser. Ele percebe que estamos a converter 3 km por todo o lado. Talvez o padrão hoje em dia seja representar todas as distâncias em quilômetros. Talvez seja para representar todas as distâncias em centímetros, mesmo dentro do sistema métrico. Você começa a ter essa habilidade de mudar as coisas ao redor. Poderíamos também representar todas as distâncias em milhas. Digamos, porém, que nós apenas decidimos mudar isso de metros, dois quilômetros, algo que pode ser uma mudança muito simples. Então, em B, ele vai e faz a mudança, talvez este pequeno algoritmo de conversão rápida e agora bater fora os dados. Os dados aqui representam medidores. O problema é que você não pode ver quem está basicamente contando com esses dados daqui. Pode haver 1000 pessoas chamando ou 1000 módulos chamando esse pequeno trecho de dados. Agora, sempre que mudamos isso, de repente todo esse ar vai quebrar um A e C e então o que estiver conectado vai quebrar porque cada um deles estava assumindo que era metros e então estava se convertendo com base nisso suposição. Então, por causa disso, agora A vai ter um problema. Vai quebrar, vai representar esse inseto estranho onde as coisas estão. Talvez, você sabe, uma magnitude um pouco para maior magnitude, um pouco pequeno, no entanto, Veja, Convertido. Não vai ser muito estranho. Talvez estivesse a convertê-lo para outra coisa aqui. Então, por causa da mudança de novo, será uma magnitude fora da nossa indiferença aqui também. Então, por causa de uma única mudança, agora quebramos um monte de módulos. E agora temos que passar por cada um desses módulos e mudá-los de novo e de novo. Dois módulos, não o maior negócio do mundo. Mas se tivéssemos 100 módulos, isso se torna um grande problema, porque vamos ter que corrigir manualmente Ah, 100 módulos. E onde não temos plantas para nos dizer quais estão quebradas? Nós só temos que consertar um correndo novamente, ver quais freios fixos, um correndo novamente, ver o que quebra e assim por diante. Ah, melhor maneira de fazer isso. O jeito que você sai dessa é com getters e centros. Então o que isso é que você cria esse tipo de interface que basicamente outros módulos podem se divertir e por que isso é importante é porque se nós mudamos os medidores aqui, nós apenas vamos mudar as duas funções aqui em baixo, obter milha e obter quilo por quilômetro. Então, nesta situação, se mudarmos de metros dois quilômetros agora tudo o que temos a fazer é apenas retornar isso diretamente . Antes, Talvez havia como, um vezes 10 ou realmente ah, dividir por eu acho que 100 para obter quilômetros de reboque e, em seguida, enviar isso para fora e, em seguida, uma milha. Há uma grande equação para isso. Agora, tudo o que fazemos é mudar isso para representar quilômetros mudar esses dois getters e centros e cada um que estava agarrando deste Todo mundo que estava pegando tudo perfeitamente bem agora porque eles estão recebendo a mesma informação. Fizemos uma única alteração em um único arquivo e tudo é atualizado em vez de tê-lo em vez de tê-lo em vez de tê-lo para que tudo esteja quebrado. A próxima coisa que temos aqui é que temos acoplamento comum. Então, com acoplamento comum, temos essa idéia de quando vários módulos têm acesso e manipulam os mesmos dados globais . Então, você pode ver que todos nós vamos ser parecidos. Mas só um pouco diferente nesta situação. O que temos é que talvez tenhamos um grande arquivo da Constance ou temos esse tipo de banco de dados quase interno onde estamos armazenando dados e tirando isso. E estamos fazendo tudo isso a partir de todos esses módulos. O problema com isso é que temos a capacidade de, por exemplo, se este escrever para ele, e então este agarra de lá e, em seguida, durante o processo de cálculo, este escreve um novo valor, e este agarra esse valor e este escreve um novo valor. Vamos começar a ter essas inconsistências estranhas, esses insetos, esse tipo de mudanças vão estar se movendo por todo o lado. Eso você meio que tem essa falta de integridade de dados, você não tem a capacidade de controlar os dados que estão chegando e variáveis podem começar a mudar. E digamos que temos um pequeno erro neste aqui. Então este módulo aqui, todos esses outros estão funcionando e de alguma forma não está sendo arejado. Mas este faz apenas uma conversão ligeiramente errada. E assim, quando ele envia esses dados para cima, ele torna essa variável corrompida. Esta variável é agora. Não há integridade com isso. Na verdade, é uma variável incorreta. Bem, o problema é que todos estão pegando dos mesmos dados globais lendo, escrevendo, empurrando, puxando esse tipo de ar que este cria vai se propagar aqui e aqui e aqui e aqui e aqui e aqui e aqui e assim por diante e assim por diante. E você vai ter esse problema onde você vai ter um bug que é incrivelmente difícil de rastrear porque o bug vai se representar em cada módulo. E você não vai saber que a pequena linha de código aqui era o ar. E é por isso que o acoplamento comum, ter essa ideia de tudo manipular os mesmos dados globais é ruim. Se você tem, por exemplo, , como uma lista de constantes que nunca mudam, isso não é certo, o tempo para ter esse tipo de todo mundo agarrando do mesmo tipo de lista gigante de A Constance. Agora pode haver maneiras melhores de criar uma lista gigante de Constance, mas eu quero diferenciar que, desde que vocês estejam saindo de lá e isso nunca mude, tudo bem. O problema aparece é que o papel manipulando-o. E se estamos manipulando isso, então temos o problema onde pequenos herdeiros podem cascata e quebrar todos os módulos. Então só queria fazer essa pequena diferença. O último é acoplamento externo. O acoplamento externo é quando vários modelos têm acesso direto ao mesmo que eu devo. Então o que isso é isso pode ser um P I. Isso pode ser, por exemplo, controlar o mouse. Talvez você tenha um programa que usa um monte de módulos para pegar dados do mouse e fazer coisas com isso. Mas vamos falar sobre isso como se fosse uma IA. O problema é o A P I. O problema com isso é que se o A P I muda o seu externo, esse é o tipo de palavra chave aqui que significa que não temos controle sobre. Não temos controle sobre como o externo funciona. Portanto, digamos que estamos trabalhando com o Google. Estamos usando um dos olhos deles. Se tivermos 1000 módulos, 1000 módulos diferentes, então temos um módulos. Ouçam os milhares de homens aqui, e todos eles estão entrando em contato com o Google PI, e chamando uma única função. Ouçam os milhares de homens aqui, e todos eles estão entrando em contato com o Google PI, O que acontece quando o Google decidir que não gostamos mais dessa função? Vamos mudá-lo e vamos mudar. Pode ser drasticamente ou talvez só um pouquinho. Vamos mudar a saída só um pouquinho. O problema é, é que agora temos 1000 módulos novamente que quebraram. Nós temos que passar e mudar a maneira como nossos módulos lidam com dados 1000 vezes diferentes ao longo de todos eles. E isso pode ser um projeto muito, muito grande e um grande problema, especialmente se você estiver usando um monte de olhos AP e isso acontece semanalmente, você pode ver a sobrecarga que estaria aqui. E se o que tivemos em vez ap I controlador. Então nós temos este pequeno controlador aqui, e todos eles falam com isso com getters e centros apropriados. E então isso fala com o AP I. Então o Google faz uma mudança, então tudo o que temos que fazer é fazer uma única mudança de linha. E então todo esse ar atualizado de acordo porque eles estão apenas falando com isso. Essa função que entrega o Google um p I. E então essa é uma maneira que você conserta esse tipo de idéia. E mais uma vez, este é o seu começo a ser acoplado pelo A P que ouvi. Mas é um passo melhor do que isso, e nós podemos meio que quebrá-lo com um pouco mais de processo de pensamento mais tarde. Mas estes são os piores casos de acoplamento. Espero que existam diferentes. São mais casos, claro, para acoplar diferentes cenários do Vincent. Isso pode acontecer. Mas espero que entenda. Faça isso. O problema sobre o tema geral aqui é que todos nós estamos acessando. Os mesmos dados estavam cavalgando e pegando dele. E se tivermos essa idéia de onde uma única linha de código pode quebrar 1000 módulos diferentes, única linha de código pode até quebrar apenas dois módulos, então provavelmente há um problema lá. Provavelmente há algo que poderíamos fazer para extrair o controlador, extrair algumas dessas informações e corrigir esse problema. A próxima palestra será falar sobre o próximo nível disso, que é um pouco melhor, e isso vai ser acoplamento médio 24. Acoplamento médio: Então vamos passar para o nosso próximo tipo de ruptura de acoplamento. E isso vai ser um conjunto ligeiramente melhor de acoplamento, mas ainda alguns problemas, e isso é o acoplamento médio. Então, à medida que nos aproximamos mais e mais para perder casal, você começará a ver que talvez alguns cenários possam realmente funcionar para essas áreas. E talvez estejamos começando a entrar na gritty nitty de, você sabe, sobre a otimização do nosso código. E esse tipo de decisão que os designers têm que tomar é, eles querem gastar o tempo extra, você sabe, projetando coisas extensivamente, ou é melhor apenas colocar o produto no mercado? Muitas vezes é melhor colocar o produto no mercado, então as pessoas podem colocar algumas dessas coisas lá e esperar consertá-las mais tarde ou apenas dizer, você sabe o que é um problema. Mas vamos lidar com isso de qualquer maneira. E então apenas tenha isso em mente é que nós não temos que ser perfeitos ao codificar software e existem requisitos diferentes, dependendo de diferentes projetos. Mas de qualquer maneira, o próximo nível de acoplamento que estamos falando é o acoplamento médio, e assim o primeiro tipo de classificações. Do lado disso, a questão comum que temos é essa ideia de acoplamento de controle. Então é quando os dados são passados que influencia a lógica interna de outro módulo. O que isso faz é quebrar a mentalidade da caixa preta. O módulo não apenas leva entrada, faz algo e, em seguida, produz saída. Agora temos essa idéia de que temos que realmente olhar para a caixa preta para descobrir o que precisamos para dialogar. Então, em vez de apenas ser capaz de inserir três, agora temos que inserir sinalizadores, controladores e interruptores para que estejamos realmente controlando os internos disso, o que novamente quebra a mentalidade da caixa preta. E requer todos os módulos que nos comunicamos com este dedo do pé. Esses interruptores estão envolvidos? Agora, onde isso se torna um problema? Bem, digamos que temos essa idéia de definir dados, então temos aqueles getters e centros estavam funcionando bem, mas em vez de no centro em vez de praias decidirem seu próprio destino, fazendo suas próprias coisas, Ele está esperando por uma bandeira de um A está dizendo a ele como operar enviando esta bandeira. Se você não ouviu falar de uma bandeira lutando apenas verdadeiro, falso ou algum outro valor que você enviar a sua. E dependendo desse valor, muda o comportamento. Bandeiras internamente estão perfeitamente bem. No entanto, quando estamos fazendo externamente, como aqui nós temos esse problema onde agora o usuário precisa saber exatamente o que está acontecendo neste módulo para controlar, seja verdadeiro ou falso, deve ser activado. E isso se torna um problema porque novamente poderíamos ter 1000 módulos diferentes tipo de comunicação e chamada esta função de dados conjunto. E se mudarmos isso em vez de verdade, talvez tenhamos feito uma coisinha em vez de verdade. Nós vamos com apenas chá em vez de, hum, falso. Vamos só com EPH. Então, em vez desses dois, nós vamos apenas uma espécie de mudança pode ser apenas a semântica, apenas olhando para ela, a estética dela em vez de, você sabe, mudança significativa real. Mas de qualquer forma, isso quebraria todos os módulos. Como cada módulo é treinado, agora está sintonizado para chamar essa bandeira. Portanto, quaisquer alterações dentro daqui agora vão quebrar cada módulo e você vê que o padrão novamente não foram capazes de mudar um módulo sem quebrar. Um monte de outros módulos, e isso é uma espécie de geral. O problema de arcos com coisas bem duplas é a ideia de que se fizermos uma mudança , quebramos um monte inteiro. Então essa idéia de acoplamento de controle é novamente quando estamos enviando bandeiras ou sinais de controle para outro módulo para tentar controlar o fluxo de dados ou as operações sobre o módulo. Isso precisa ser dividido em uma maneira mais inteligente para que talvez tenhamos um conjunto de dados, determinado tipo nos dados do conjunto, outro tipo e, em seguida, definir dados tipo diferente. Sabe, estou dizendo que temos três dados de conjunto diferentes e isso nos permite, em vez de ter que colocar sinalizadores de controle, podemos chamar qualquer conjunto de dados que precisamos nessa situação. E então, em vez disso ter esse tipo de módulo de controle estranho onde tudo está controlando, agora temos um p I. E estamos todos chamando o P I. Então, se você fizer mudanças, podemos fazer inteligente muda para isso, um p I. A próxima idéia é este acoplamento estrutura de dados e com estrutura de dados. Casal no que temos é quando vários módulos dizendo compartilhar a mesma estrutura de dados. E assim estrutura de dados é apenas como este em matriz ou uma lista ligada ou algum outro tipo de estrutura maneira que mantemos os dados juntos Agora o problema com isso é se estamos chamando diretamente a partir dessa estrutura de dados. E se quisermos mudar a estrutura de dados? E se houver algo mais inteligente, uma maneira melhor de implementá-lo? Bem, de novo, descendo aquela linha de acoplamento ruim? Vai quebrar vários módulos. Digamos que estamos usando um raio de chamadas. Então nós estamos dizendo, você sabe, um, matriz, vamos apenas dizer que este é um raio A Então nós estamos dizendo como um cinco. Então estamos fazendo chamadas diretas aqui. Um de estão realmente fazendo um de dois e depois zero. É deletes. Isso é um 101234 quatro e cinco. E então este é um de três. Talvez estejamos definindo um igual seis ou algo assim, blá , blá, etc. Mas o problema com isso, o problema que temos sempre que chamamos diretamente deste array é o que se quisermos mudar isso para uma lista vinculada e uma lista vinculada? Parece algo como isso vai a lista vinculada. Estas chamadas não funcionam. Então, se nós nos mudamos, agora de repente temos esse problema onde todos esses quebrem cada chamada como esta agora está quebrado. Temos que mudar um monte de módulos. Uma maneira mais inteligente de fazer isso seria ter quase uma classe de controle de controlador de dados. Então, em vez de chamar funções diretas para a matriz, o que fazemos é chamar um getter e um centro aqui, e isso iria falar com a estrutura de dados. Dessa forma, sempre que mudamos a estrutura de dados ao redor, nós apenas mudamos cada getter e setter aqui. E tudo isso funcionaria perfeitamente bem novamente. Eso como em vez de, você sabe, este tipo de cinco estavam fazendo uma ligação direta. Vamos dizer, talvez obter índice e então vamos passar um cinco. Desta forma. O funcionamento interno de como conseguimos o número cinco. Não precisamos saber. Não vamos ligar diretamente. Em vez disso, estamos realmente tomando esse tipo de nós estamos aumentando essa dependência, e estamos permitindo que isso controle toda essa lógica de controle. Portanto, novamente, se nós apenas trocá-lo para outra estrutura de dados inju lista vazou ou algum outro tipo de maneira de armazenar informações que criamos. Nós não podemos apenas fazer um par rápido de atualizações nesta classe controlador em todos os nossos módulos funcionou perfeitamente bem novamente. Então isso é o acoplamento da estrutura de dados. Isto é um pouco mais comum. Não é a pior coisa do mundo porque, você sabe, trocar estruturas de dados não é algo que acontece o tempo todo, e nós geralmente não temos um monte de módulos falando com a mesma estrutura de dados, mas acontece. E nessas situações, queremos pensar em vez de talvez entrar em contato diretamente com a estrutura de dados procurando construir uma classe de controle para que abstraímos esse controle um pouco . Então, estas são duas ideias principais de acoplamento médio. Você veria como eles não são tão ruins quanto os outros em que estamos fazendo mudanças únicas em quebrar milhares de coisas. No entanto, eles podem ser ruins se estamos fazendo pequenas mudanças em certas áreas de certas maneiras muito específicas , nós ainda quebramos um monte de módulos. Na próxima eleição, vamos cobrir o último tipo de lado das coisas, que vai ser as coisas de acoplamento solto que estavam indo para áreas que queremos usar um pouco de acoplamento para fins estratégicos, mas mantê-lo o mais solto possível. 25. Acoplamento de 4-8: Então o último nível de acoplamento é o desta idéia de acoplamento solto. Então, com o acoplamento solto, o que temos é esse ótimo estado de comunicação entre módulos. Assim, nesta situação só estavam tendo informações muito pertinentes sendo passadas de um módulo para o outro. Então, o muito frouxamente acoplado, que significa que nós poderíamos tipo de mudar um para outro e não haveria um grande problema . Talvez precisemos mudar uma linha de código aqui e ali para que funcione. Mas não vai ser este projecto gigante. Além disso, não vamos ter esse problema daqueles bugs estranhos em cascata por todo o lado porque o trem de dados que está sendo passado vai ser muito fácil de rastrear. Agora não estamos mirando não é nenhum acoplamento. Portanto, há esta categoria de nenhum acoplamento. Mas isso só significa que não há comunicação entre módulos. Ou talvez tenhamos apenas um módulo muito, muito, muito grande. Então, você sabe, este módulo que só tem informações todo o caminho para baixo, é completamente e totalmente louco. E você já pode, você sabe, entender que isso seria um problema também. É isso? Basta ter um único módulo e dizer: “ Sim, Sim, não há nenhum casal aqui. Isso é um problema que não é um anti-padrão. Isso é o que chamamos de um padrão anti, que é o oposto de um padrão produtivo. E o pouco também quebra o que nosso próximo inquilino é, que é coesão, porque isso não teria um propósito singular. Isso teria basicamente o propósito de todo o aplicativo. Então isso também não é o que vamos fazer. Então, nenhum acoplamento não é onde fomos em frente. Isso não é nenhuma comunicação. E nossos módulos precisam conversar uns com os outros. Eles precisam se comunicar de alguma forma. Tem de haver ligação entre eles. Então isso significa que ficamos com essas duas áreas de acoplamento. E essa vai ser a idéia de acoplamento de dados e a idéia de acoplamento de mensagens. Então, o que? São um casal no que temos? É quando dois módulos compartilham ou passam os mesmos dados. E o que isso significa é que nós apenas temos dados em um, e nós estamos passando para outro dado ou outro módulo passando esses dados para outro módulo . Lembre-se, estamos falando sobre colocar um getter ou um centro para o centro. O que temos que passar? Temos que passar dados para definir a informação aqui neste módulo. Isso é uma passagem de dados. É uma ligação entre os dois. Se mudarmos os dados aqui, algo vai mudar aqui. Se decidirmos que queremos passar um tipo diferente de dados para ser, bem, então isso vai acontecer. Talvez tenhamos que fazer uma mudança e ser aceitar esse novo tipo de dados. Então, mesmo que a mudança seria pequena, que apenas uma pequena linha de código lá para mudar, ainda há uma pequena quantidade de ligação. No entanto, não podemos realmente passar por isso porque os módulos têm que se comunicar. Temos que ser capazes de passar dados de uma ponta para a outra. Então este acoplamento não é ruim. Este é apenas o melhor estado de acoplamento novamente. Vai haver um pouco disso. Isso é perfeitamente bom. A outra ideia é o par de mensagens, e que é quando mensagens ou comandos são passados entre módulos. O que queremos dizer com isso é se talvez tenhamos este é o nosso Isar inicial então temos um aplicativo, e este inicializar é o aplicativo. E então talvez aqui nós temos Talvez isso comece os serviços de fundo ou algo assim, e então isso liga e faz o Isso vai ser o gerente de notificações. Este aqui é talvez o gerente de backup. Isto aqui é potencialmente, não sei, talvez como alguns de volta aos cálculos. Então cálculo Apenas sofá para encurtar bem ali. E assim você pode ver que isso é realmente um bom conjunto aqui. Nós não temos nele. Ele chama para baixo para um comando para iniciar o material de fundo, o material de fundo que particiona muito inteligentemente para a tarefa de calculadora de fundo, a tarefa de backup em segundo plano, a tarefa de notificação em segundo plano. E todos eles começam. E eles passaram comandos em suas palavras, você sabe, Be está dizendo isso para operar a cada 12 horas. Isso funciona a cada três horas para parar a taxa a cada 14 horas, etc, etc., seus comandos sendo passados, suas mensagens. Estão a dizer que deves começar esta tarefa. Ei D, você deveria começar essa tarefa. Eles não estão indo no nitty gritty que eles não estão controlando, lembre-se, essa é a diferença. O acoplamento de controle não significa? Estamos passando bandeiras em cada um deles para mudar o controle, estávamos apenas dizendo o que precisa ser feito. Então, nesta situação, estamos dizendo, o processo de cálculo deve ser executado. E, em seguida, este figura dado no conjunto de parâmetros no estado atual do aplicativo, o que isso significa e mesmo com o backup. Não estamos passando comandos ou não. Passando bandeiras estavam apenas dizendo, Faça a operação que você deve dio e no backup gerenciar vai fazer isso apenas que ele vai olhar para o estado do APP e ele vai fazer. É o trabalho. Ele fará backup do estado do APP para onde quer que ele precise ir. E então é isso que o acoplamento de mensagens é, e você pode ver qual a combinação de bagunça, acoplamento e acoplamento de dados. Podemos criar qualquer aplicativo que precisamos. Nós não precisamos de nenhum outro casal ing para basicamente trabalhar nossa aplicação ou nosso programa de qualquer forma, forma ou forma. Bem, dado um pouco, há algumas situações em que você vai precisar talvez acoplar um pouco mais . Talvez se você juntar mais uma luva minúscula. Talvez você tenha ido até o acoplamento médio para uma seção de seu aplicativo que pode economizar 200 horas de trabalho. Ou pode ser Mórmon que pode ser mantido. E essas situações são boas. Mas nosso objetivo aqui, nossa idéia é que queremos nos soltar o mais possível. Queremos reduzir a web de dependências dentro de nossa aplicação. E esse é o tipo de objetivo de tudo isso é acoplamento solto aqui novamente. Não queremos ir com nenhum acoplamento. Queremos essa ideia de acoplamento solto. 26. Conclusão de acoplagem de 4-9: um dos seus embrulhos com um par de pensamentos finais aqui. Então estamos todos na mesma página. medição do acoplamento à medida que projetamos e desenvolvemos é importante. É por isso que temos estado a passar este tempo todo. É aí que você se concentrou em muita coisa. E não é só o suficiente para planejar o que precisamos para planejá-lo. Bem, o que quero dizer com isso é que podemos ter um plano de 1000 páginas realmente em profundidade. Mas se são apenas projetos realmente horríveis de módulos muito bem acoplados, não importa que tenhamos o plano dele. Nós o projetamos mal. Ainda não pensamos em casal. Não pensamos em coesão. Nós não pensamos sobre a idéia de mantê-lo e ser capaz de mover e alterar o aplicativo ao longo do tempo. Tudo o que fizemos foi colocar nossas idéias no papel, não pensar em uma solução mais inteligente, e então vamos desenvolver isso. Então só porque temos um plano não significa que seja um bom plano. E é isso que a idéia do design é não só para o planeta, mas para torná-lo um bom plano. E, finalmente, estamos tentando apontar para o acoplamento de casal solto e enfraquecer justificar na escrita qualquer coisa mais forte. E assim, como eu estava dizendo no anterior, talvez haja uma situação em que você não pode pensar em uma solução melhor do que fortalecer ligeiramente como eu estava dizendo no anterior, talvez haja uma situação em que você não pode pensar em uma solução melhor do que fortalecer ligeiramenteo acoplamento direto, você sabe, o acoplamento direto, você sabe, torná-lo um pouco mais apertado nessas situações. Não bata na cabeça, tentando deixá-lo o mais solto possível, tentando adicionar, Você sabe, Você sabe, 85 módulos adicionais para que você não precise, para você possa levá-lo para baixo para aquele acoplamento muito solto . Não é para onde queremos ir. Então, nessas situações, apenas justifique por escrito, apenas, você sabe, explique para alguém que possa estar olhando para isso. Por que usamos um acoplamento mais apertado, mesmo que seja apenas, uh, o outro plano teria exigido tempo adicional de desenvolvimento sem nos poupar tempo de manutenção. Algo assim. Escrever e , seguir em frente,seguir em frente com o design. Mas, no geral, estamos tentando apontar para esse acoplamento solto. É o nosso objectivo. É como um alvo. Estamos tentando atingir o mais próximo possível do centro. Se estamos aqui de vez em quando ou talvez aqui de vez em quando, tudo bem. Mas estamos apontando para o centro. Estamos tentando chegar o mais perto possível do objetivo central. E se fizermos isso, estamos fazendo nosso trabalho corretamente. Na próxima palestra, vamos passar pelo outro lado, que é a ideia de coesão. Coesão é interessante, e é uma espécie de quase vai contra o acoplamento de uma certa maneira, que exigirá um pouco de equilíbrio. Então vamos pular ali. 27. Introdução a coesão: Então vamos para o outro lado da moeda, se você quiser, se você quiser, e falar sobre a outra idéia realmente importante ao dividir as coisas em módulos. E essa é a ideia de coesão. Então, nas últimas palestras, temos falado sobre essa ideia de acoplamento onde não queremos que os módulos sejam muito fortemente associados uns com os outros, mas com a coesão. O que queremos é que cada módulo seja o mais definido possível. Reuni-lo apenas realiza uma única tarefa. Então não queremos ter um monte de módulos fazendo um monte de coisas, que significa que não queremos módulos realmente grandes ou este módulo faz um pouco nesta categoria. Este modelo faz um pouco nessa categoria aqui e nesta categoria. E então, claro, o outro exemplo é apenas um realmente grande, onde você só tem um único arquivo fazendo tudo. Queremos que eles sejam muito focados para que possamos tirar as coisas, e podemos meio que misturar e combiná-las. Uh, nós temos essa idéia de modularidade onde poderíamos pegar um módulo e substituí-lo por outro módulo e ele funcionaria perfeitamente. Então, por exemplo, se este fosse o módulo de cor vermelha e este fosse uma cor, talvez módulo verde, poderíamos tirar o módulo vermelho e colocar o verde direito em seu lugar, e ele funcionaria perfeitamente bem por causa de como definidos e quão específicos esses dois são. E isso é o que procuramos com a coesão. Agora estes dois. Como eu disse, eles trabalham uns contra os outros. Você pode ter um conjunto muito, muito forte muito fortee coeso de módulos que são muito, muito bem acoplados, e você pode ter um conjunto muito, muito frouxamente acoplado de módulos que é muito, muito fraco na coesão. O exemplo que eu gosto de usar para isso é se nós temos um arquivo gigante, Se nós temos um único arquivo gigante fazendo tudo bem, por definição, nós realmente temos acoplamento muito solto. Não há ligação com nenhum outro arquivo aqui. Este módulo é frouxamente casal que não tem nenhum link ings. Poderíamos, na verdade, dizer que não se trata de um acoplamento nesta situação, que seria bom e acoplamento. Mas com isso temos a coesão mais fraca de todas. Então o que temos aqui é um arquivo que faz tudo e, portanto, não tem propósito. Não tem nenhum fator definidor do que é suposto dialogar. E por causa disso, em vez de apenas procurar um ou outro, temos que tentar fazer com que os dois se encontrem. Temos que encontrar um equilíbrio. E é aí que vamos com este princípio da coesão forte e do acoplamento solto. Nós não vamos ser capazes de ficar perfeito em cada lado, mas o que nós estamos procurando se ambos fossem como gráficos como, uh como este aqui, nós estamos olhando para tentar toe mah, maximizá-lo bem no centro aqui. Estamos olhando para tentar otimizar nosso programa para que ele seja muito bem e frouxamente acoplado e, ao mesmo tempo, bastante coeso. Se pudermos fazer isso, temos um ótimo programa. Temos um grande design e vai tornar o processo de manutenção e construção muito mais fácil. Então, as próximas palestras, vamos começar a entrar em alguns dos diferentes níveis de coesão como fizemos com o acoplamento e ver algumas das armadilhas comuns e outras coisas que vêm com a construção em relação ao acoplamento 28. Coesão fraca: Então vamos começar a nossa primeira categoria com uma coesão fraca. Por isso, a coesão é a pior forma de coesão. Significa que não temos muita coesão. E lembrem-se, queremos coesão forte e acoplamento solto. Então, com coesão fraca, o que temos é que temos esses módulos que são construídos, mas eles realmente não têm um propósito. Isso cria essa idéia de falar código espaguete, o que significa que pode haver talvez 1000 módulos diferentes em um arquivo. Mas nenhum deles tem um propósito, e nenhum deles está ligado de qualquer maneira concebível. Portanto, qualquer outra pessoa tentando se juntar ao projeto não teria idéia de como qualquer coisa funciona. Não haveria nenhum conjunto ou orientação, nada que eles pudessem seguir para descobrir. Eles só teriam que brincar com ele até aprenderem. E isso realmente retarda a produção porque você não pode contratar mais pessoas sem todo esse tempo que vai demorar para colocá-los a par. Então, com coesão fraca, temos algumas categorias para começar. O 1º 1 é a sua ideia de coesão coincidência, então coesão coincidência significa que a única razão que essas idéias, atividades e coisas estão juntas neste módulo é só porque eles estão no mesmo arquivo lá, coincidentemente juntos. Então temos um arquivo, e colocamos um monte de coisas aleatórias diferentes nele. Então, coincidentemente, eles têm essa associação. Eles são grupo juntos porque dizemos que eles são grupo juntos e você sabe um exemplo disso pode ser limpo o assento do carro restaurante direito relatório Livro vôo de Dallas, Texas. Não há nenhuma combinação lógica dessas coisas. Não há nada focado nisso. É apenas um monte de tarefas aleatórias aqui, e isso é realmente isso pode ser um passo mais longe do que coincidência. Só porque são atividades, podemos até ter algo como onde colocamos E aqui. E é algo como um substantivo como cachorro. E agora você. Agora nem sequer são todas as atividades. Agora eles são ainda mais aleatórios. E então, quando você chegar a este ponto de apenas aleatoriedade, isso te deixa para baixo muito coincidência. E como eu disse, é impossível desmascarar algo assim porque você vai ter, tipo, um monte de arquivos em tudo. Faça isso e, em seguida, eles estão todos ligando aleatoriamente, os outros arquivos e não faz qualquer sentido o fluxo do programa. Alguns exemplos disso são como um único programa de arquivo. Então, como estamos falando com aquele único arquivo gigante em todo o programa é executado a partir daquele talvez um arquivo de script Java ou arquivo Java ou algo assim. Trata-se de uma coincidência de coesão. Não há nada vinculando isso juntos, exceto que eles são todos parte do mesmo programa, e eles estão todos no mesmo arquivo, o controlador de incompatibilidade também. Então, se temos, por exemplo, como um controlador de visualização de modelo, temos uma classe de controlador que estamos tentando, você sabe, passar tudo para. Temos essas ideias e estamos tentando criar um código melhor. Mas se nós realmente não dar um propósito a ele, e nós apenas colocar tudo naquela classe controller, ele se torna coincidência também. E talvez o pouco sobre o lógico se eles são todos controladores, se eles são todos realmente fazer atividades. Mas geralmente há algo neles que não faz e meio que cai de volta para esta categoria, e então, como eu disse, código de espaguete onde tínhamos apenas todos esses módulos que todos não têm absolutamente nenhum propósito conversando um com o outro. Então isso é coincidência. Coesão apenas arquivo. Mas acima do que tem é que ele está no mesmo arquivo. A próxima é essa ideia de coesão temporal, e isso significa que estavam ligados entre si porque os acontecimentos acontecem por volta da mesma época. E se fôssemos para um exemplo do mundo real aqui, seria como dentes escovados. Tomar banho, café da manhã. Acorde. O que são estes? Há como uma manhã seu filho adolescente? Então todos eles estiveram bem no início da nossa manhã, então eles estão meio que há uma ligação entre si. Eles são melhores do que isso aqui. Mas, novamente, não é muito útil porque ainda há atividades que estão por todo o lado. Aqui temos algo acontecendo com as coisas acontecendo. A casa de banho. Um na cozinha. Este está no quarto. Alguns deles estão consumindo itens, alguns deles apenas usando outros. Alguns deles estão consumindo itens, Alguns deles estão limpando. Alguns deles são uma mudança de estado. Então vamos do sono para acordar. Eles são todos completamente diferentes no seu lá. Quantidade de controle, sua quantidade de mudar as coisas ao redor deles e se você está pensando no programa, você pode ver isso é bem como Imagine se algo estava acontecendo na frente e isso é e talvez tipo, o banco de dados aqui. Isto é puramente na parte de trás pode ser nos servidores de descontar. Alguns deles estão mudando de frente invariável, alguém mudando de volta invariável. Alguns estão pegando do banco de dados. Eles estão por todo o lado, mesmo que eles aconteçam relativamente ao mesmo tempo novamente, não é muito coeso. E um exemplo disso é como um programa, como encerrar atividades ou fazer, hum, talvez iniciar atividade. Coisas assim são essas coisas que se ativam em um determinado momento ao mesmo tempo, e isso é a coesão temporal. A próxima é a coesão lógica. Então estamos ficando um pouco melhores com a coesão lógica e, nesse sentido, suas atividades que estão ligadas na mesma categoria geral. Então o que temos é dirigir para Dallas, voar para Dallas, pegar trem para Dallas e pegar barco para Dallas. En