Aula4_Projeto_Software

In this information, the speaker discusses software project design. They cover various topics such as the motivation behind software design, the importance of analysis and project phases, the use of models in analysis and design, concepts of software architecture, the importance of modularization, and different architectural styles. The speaker also emphasizes the need for functional independence, cohesion, and low coupling in software modules. They discuss different models for data design and architectural design, including examples of architectural styles such as data-centric, flow-based, layered, and object-oriented. The speaker concludes by mentioning the importance of interface models in defining navigation, communication, and interaction within the software system. Aula 4 Projeto de Softwares. Agora nós vamos falar de projeto de software. Então vamos lá, iniciando com roteiro da aula contextualização, motivação, objetivos, conceitos de arquitetura de software, que seria então a abstração e refinamento, arquitetura e modularidade, independência funcional, refabricação, modelos de projeto, dados, arquitetura, interface, componentes e por fim referências. Vamos iniciar com motivação. Na análise fazemos os modelos de análise ou análise dos requisitos. No projeto nós fazemos o design do software e todo o detalhamento de como o software deverá ser construído, incluindo arquitetura, design e implementação, deve ser feito na fase de projeto do ciclo de vida de desenvolvimento. O documento a ser entregue nesta etapa pode seguir um modelo de especificação de requisitos de software, que é o ERS. Objetivos principais, finalizar a modelagem do software definindo um mapa de componentes, finalizar a especificação de requisitos de software, ERS. O produto final desta fase é uma documentação que poderá ser entregue para uma fábrica de software ou programadores. Modelos de análise e projeto ou modelos de análise versus projeto. Modelos de análise, ele tem alta abstração, diagramas, casos de uso, IDF0, DFD e DER, que é o diagrama entidade relacionamento. Nós temos então atividades, classes, sequência e estado e etc. Esses então são os diagramas do modelo de análise, repetindo casos de uso, o IDF0, DFD e o DER, que é a entidade relacionamento, atividades, classes, sequência e estado e etc. Os modelos de análise são detalhados e reagrupados em modelos de projeto. Os modelos de análise são detalhados e reagrupados em modelos de projeto, em dados, classes, arquitetural, de interface e de componentes, mapa de componentes. Continuando então, nós estamos agora em conceitos de arquitetura de software. Conceitos de projeto. Arquitetura de software é a estrutura hierárquica dos componentes, como construir bem esses módulos que se interrelacionam. Modularidade. O software é dividido em componentes e integrados para formular o sistema. Arquitetura possui modularidade. É inviável colocar todos os códigos em um único documento, então se faz a modularização, quebrando esses códigos em vários componentes. Conceitos de objeto. Abstração. Pode ser de alto nível ou baixo nível, além de procedural ou dados. Procedural nós estamos falando na parte comportamental, ou dados nós estamos falando que pode fazer abstrações na parte estrutural. Refinamento. Inverso da abstração. Refabricação. Os modelos de projeto ou código são refeitos, sem mudar o seu funcionamento, mas melhora a estrutura interna e a manutenção. Custo de modularidade versus integração. Se o custo de resolver dois problemas juntos for maior do que resolvê-los separadamente, implica em modularizar o código ao máximo. Dividir para conquistar. Quanto mais módulos, melhor. Então vamos de novo. Se o custo de resolver dois problemas juntos for maior do que resolvê-los separadamente, implica em modularizar o código ao máximo. Dividir para conquistar. Quanto mais módulos, melhor. Porém, existe um custo de integração. Assim, existe uma região de custo mínimo para um número de módulos de um software. Aqui nós temos um gráfico, onde o eixo x é o número de módulos e o eixo y é o custo. E é um gráfico em exponencial. Ele tem um gráfico em exponencial crescente, que é a integração. Ou seja, quanto maior o número de módulos, maior o custo. E nós temos um gráfico de exponencial decrescente, onde a modularidade, ou seja, está encostado o mais alto no custo e vai caindo até o número de módulos no eixo y. Ou seja, existe uma região que esses dois exponenciais estão invertidos, como se fosse um copo, uma taça. Então, a região de custo mínimo depende de como você está modulando o sistema. Interdependência ou independência funcional. Coesão. O módulo é coeso e se realiza uma única tarefa. Acoplamento é uma medida de interconexão entre módulos. Independência funcional é conseguida através de alta coesão e baixo acoplamento. Isso é independência funcional. Voltando para a coesão, que é um módulo, o módulo é coeso e se realiza uma única tarefa. Então, exemplo, se você está fazendo um módulo de impressão de dados, você não faz sentido você colocar no mesmo módulo a leitura de dados. O ideal é fazer um módulo para cada funcionalidade de impressão e de leitura. Esse é apenas um exemplo da parte de coesão. Agora nós vamos para modelos de projeto de dados. Define a estrutura de dados que será utilizada no sistema. Através do diagrama de classes, classes de modelo ou classes de entidade, iniciadas no modelo de análise. Fazer agora o detalhamento. Definir o conteúdo de cada objeto de dado, buscar alta coesão. Definir a visibilidade de objetos dos componentes, buscar baixo acoplamento. E, quando aplicado, detalhar também o modelo entidade relacionamento. É importante frisar que o conteúdo de cada dado busca alta coesão, ou seja, definir o conteúdo de cada objeto de dado busca alta coesão. E definir a visibilidade de objetos dos componentes, buscar baixo acoplamento. Então, definir a visibilidade de objetos de componentes busca baixo acoplamento. Modelos de projetos arquiteturais. Estilos arquiteturais. Nós temos, então, arquitetura centrada nos dados, arquitetura de fluxo de dados, arquitetura de camada e retorno, arquitetura orientada a objetos e, por fim, arquitetura em camadas. Independente do estilo arquitetural escolhido, usar uma ou várias arquiteturas que possuam independência funcional. Então, aqui a gente tem os estilos, o exemplo de estilo arquitetural de software, que é centrado nos dados. Aqui a gente tem um exemplo que, no centro, você tem um sistema de banco de dados e os módulos todos são seis módulos conectados a ele. Então, cada módulo é independente, se conecta diretamente ao banco de dados. Esse é o estilo arquitetural. Ele pode ser uma situação, ele pode ser bom em uma situação, mas em outras não. Exemplo, segurança. Cada módulo é acessar o banco de dados. Isso é ruim para a segurança. Portanto, a solução seria criar um módulo para fazer essa consulta ao banco de dados e se conectar aos demais módulos, como se fosse um anel envolto ao sistema de banco de dados e todos os módulos que precisasse acessar o dado teria que acessar esse anel que está conectado ao banco de dados. Exemplo de estilo arquitetural de software de fluxo de dados. Aqui nós temos, então, como se fosse um fluxo mesmo de dados, em que você tem, então, um processo que se ramifica em dois e, depois, esse que é ramificado em dois, ele se une a um e o outro a um e até o final, ok? Ou seja, ele transmite, tipo um tubo, uma pipe, que transmite os dados e o filtro de processo de dados. A gente tem, então, um exemplo de estilo arquitetural de software de camada e retorno. Então, o programa principal, ele se quebra em três, subdivide em três, em entrada, processamento, em saída e cada um desses se subdivide em dois. Então, a entrada se subdivide em dois, processamento em dois, saída em dois. E da entrada, o primeiro que se subdivide em dois, ele subdivide mais dois e o outro não. O processamento tem um segundo que subdivide em dois, que também se subdivide em mais dois e a saída se subdivide em mais dois, que seriam os subprogramas. E aqui, pode enxergar o IDEF0. O IDEF0 é esse modelo de camada e retorno. Agora, nós temos, então, um exemplo arquitetural de software orientado a objetos e mapas de componentes. Então, aqui são dois módulos separados, um módulo conta e um módulo cliente. No módulo conta, você tem a entidade principal, que é a conta, que ela é subdividida em duas subentidades, ou seja, duas outras entidades, que é a conta corrente e conta investimento. Já no segundo módulo, você tem o módulo correntista, que é o módulo cliente, em que a entidade correntista, ela é dividida em pessoa física e pessoa jurídica, que são outras duas entidades, ok? Então, a dica, toda vez que se tem uma herança, você pode fazer um agrupamento nesse componente, ou seja, ligando, então, a entidade principal. E essa estrutura possui independência funcional, ou seja, alta coesão. Há uma ligação da entidade contra a entidade cliente, mas somente na entidade principal. As subentidades, que são aquelas que se caracterizam no modelo herança, elas não são ligadas. Elas são ligadas somente à entidade principal. Por exemplo, na conta, entidade conta, as entidades conta corrente com a entidade investimento é ligado. E na entidade correntista, ela tem as duas heranças dela, que é a pessoa física, a entidade pessoa física e a entidade pessoa jurídica, ok? Essas entidades que são heranças, elas são contas filhas, ok? Então, esse é o estilo arquitetural de software orientado a objetos e mapa de componentes. Essa estrutura possui independência funcional, alta coesão, pois o modelo de conta só trabalha com conta e o modelo de cliente só irá trabalhar com cliente. Agora, a gente vem aqui com o exemplo de estilo arquitetural de softwares em camadas. Esse daqui, ele tem um modelo de três camadas. Camada de apresentação, que é a view, a camada de negócio, que é o control, o correto de controle e a camada de dados, que é o model. Então, você tem o VCM, que é o view, control e model. Novamente, o view é a camada de apresentação, a camada de negócio é o controle e a camada de dados é o model. Esse MVC, que é o model, view e control, que é o MVC, ele é o mais clássico possível, ok? E dentro desse processo, você tem também um esqueminha que mostra o control numa entidade superior ligada ao view e o model, como se fosse um circunhub, um ligado ao outro. Na verdade, nenhum sobe, o view sobe o nível de controller, agora o model não. O model se liga ao view e o view ao model e o controller aos dois, ok? Um exemplo simples. Três modelos de interface, agora, definem. Quem são os modelos de interface? Ele define um mapa de navegação entre as interfaces gráficas do sistema, a interface entre os dois, entre os componentes de software e a interface em um componente, ok? A interface de comunicação dentro de cada componente. Quatro, modelos de projetos a um nível de componente. Então, a gente tem, define as estruturas de dados, algoritmos, características de interface e mecanismos de comunicação alocados a cada componente de software. Então, é a última fase de documentação antes do código. Assim, toda a informação para o programador deve estar descrita. Esse, então, são os modelos de projeto ao nível de componente. Novamente, eles definem as estruturas de dados, algoritmos, características de interface, mecanismos de comunicação alocados a cada componente de software, ok? Um dado importante, aqui você pega, pode pegar cada componente e vai detalhar tudo. Só não pode colocar o código da especificação, né? Porque aí você vai estar codificando. Mas é preciso descrever os algoritmos, seus códigos e o seu grama. Especificação de componente, software ERS. Ele é, a prática dele é recomendada no IEE 830, ok? Que é uma recomendação. Pode-se usar esse modelo IEE 830 para completar a documentação no ER. Então, modelo simplificado para simplificar um componente, para especificar um componente. Então, você precisa do nome do componente, descrição, classes. Nas classes ela quebra em atributos, né? Métodos que também quebrem assinatura, algoritmo e algoritmo e fluxograma e diagramas. Pseudo código, OSL, etc. 4, ele quebra ainda em modelo de entidade relacionamento. Novamente, esse aqui é o modelo simplificado, ok? Para especificar um componente. Os 5, interface entre componentes. Os 6, interface gráfico. 7, especificação de teste. E o 8, etc, tá? Vamos, então, agora as referências, né? Que é do livro que o professor citou e os demais são somente exemplos aqui de entidades de classes, né? De mapa de componentes, né? De vários modelos para você fazer um modelo ideal, ok? Então, com isso a gente finaliza a aula 4.