Aula5_Projetos_Software_Modelos

In this information, the main ideas discussed are the concepts of software architecture, the importance of modularization, and the interdependence between modules. The lecture also covers different models of project design, such as data models and architectural models. The goal is to achieve high cohesion and low coupling between modules. Different architectural styles, such as data-centric architecture and object-oriented architecture, are also mentioned. The lecture emphasizes the need for balance between the number of modules and the cost of integration. Aula 5, Projeto de Software. Roteiro desta aula, contextualização, motivação, objetivos, conceitos de arquitetura de software, que dentro você tem abstração e refinamento, arquitetura e modularidade, independência funcional e refabricação. Depois vamos falar de módulos de projeto, que é composto de dados, arquitetura, interface e componente, e por fim referências. A contextualização dentro do processo, vem o processo gerência e depois vem o rapito. Rapito, requisito, análise, projeto, implementação, teste e operação. Lembrando que o requisito, você pode usar então os diagramas de fluxo, diagrama de entidade relacionamento, IDF zero, e na análise você usa as classes, as sequências, a abstração. No projeto, o mapa de componentes, o final da ERS detalhado, enfim, esses são os detalhes. Então nós estamos na fase de projeto, que é o projeto de software, que você tem lá a assinatura do contrato. Continuando a motivação, na análise fazemos os modelos de análise ou análise de requisitos. No projeto, nós fazemos o design do projeto, 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 o modelo de especificação de requisitos de software, ou o ERS. Objetivos principais, finalizar a modelagem do software definindo um mapa de componentes, finalizar a especificação de requisitos de software, novamente, especificação de requisitos de software, é o ERS. E por fim, o produto final desta fase, é uma documentação que poderá ser entregue para uma fábrica de software ou programadores. Modelos de análise versus projeto. O modelo de análise, ele possui autoabstração, que são os diagramas, casos de uso, o IDF0, o diagrama de fluxo, o DFB, o DR, que é o diagrama de entidade relacionamento, depois você tem então as atividades, as classes, sequência e estado, etc. Os modelos de análise são detalhados e reagrupados em modelos de projeto, em dados e classes, arquitetural, de interface e de componentes, que seria o mapa de componentes. Então, há uma diferença aqui entre os modelos de análise, que são detalhados e reagrupados em modelos de projeto. O poteiro desta aula ainda, nós estamos na fase de conceitos de arquitetura de software. Conceitos de projeto. Arquitetura de software é a estrutura hierárquica dos componentes, ou seja, como construir bem esses módulos que se interrelacionam. Então, o conceito de projeto, você tem a arquitetura de software e você tem a modularidade. A modularidade. O software é dividido em componentes e integrados para formar o sistema. É 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. Ou seja, a arquitetura possui modularidade. Conceitos de projeto. Nós temos três, que é a abstração, refinamento e refabricação. A abstração pode ser de alto nível ou baixo nível, além de procedural ou de dados. Quando você fala procedural, pode fazer abstrações na parte comportamental. E quando você fala de dados, pode fazer abstração na parte estrutural. O que é refinamento? Refinamento é o inverso da abstração. E a refabricação? Os modelos de projeto ou códigos são refeitos, sem mudar o seu funcionamento, mas melhora a estrutura interna e a manutenção. Agora, vamos falar de 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. Ou seja, 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 vemos um plano cartesiano em que o eixo x é o número de módulos e o eixo y é a custo. Então, ou seja, quando você fala em integração, quanto mais módulos, a integração dos módulos, você tem um gráfico que é uma exponencial. Ela começa lá no zero, na origem, e ele vai subindo exponencialmente à medida em que vai avançando para a direita o número de módulos. De forma que você tem um ponto mais alto da exponencial que é a integração. Ou seja, o custo é baixo lá na origem e ele é alto à medida que você vai crescendo o eixo y. Já a modularidade é o contrário. Essa exponencial tem a sua modularidade alta lá no custo alto. Ou seja, quanto mais módulos, mais alto lá é. E o custo dela vem baixando na medida em que o eixo x vai crescendo. Ou seja, ela vai diminuindo aquela exponencial. Ou seja, você tem uma região, então, que é o cruzamento dessas duas exponenciais, como se fosse uma taça. Ali no meio, você tem uma região de custo mínimo, que depende de como você está modulando o sistema. Ok? É isso. Quanto maior o número de módulos, maior a integração. E quanto menor o número de módulos, você tem, então... Aliás, desculpe. Quanto maior o número de módulos, maior a integração. E quando você tem um menor número de módulos, você tem um maior custo. Curioso isso, né? Ou seja, o custo abaixa à medida que você tem menos módulos para serem entregues. E o custo aumenta à medida em que você tem maior quantidade de módulos para serem integrados. E você também, da mesma forma, você tem um ponto de vista do custo. Ele vai caindo à medida que o número de módulos ele abaixa, mas tem um ponto ótimo, quando você une esses dois gráficos. Então, necessariamente, não quer dizer que muitos módulos você tem um custo alto ou baixo. Depende desse custo mínimo, de região mínima de custo. Interdependência funcional. Bom, a interdependência funcional, ela tem três pontos a serem falados. Primeiro é a coesão, segundo é o acoplamento e o terceiro é independência funcional. Quando se fala em coesão, um módulo é coeso, se realiza uma única tarefa. Exemplo, se você está fazendo um módulo de impressão de dados, não faz sentido você colocar nesse mesmo módulo a leitura de dados. O ideal é fazer um módulo para cada funcionalidade de impressão e de leitura. Acoplamento, é uma medida de interconexão entre módulos. Independência funcional, é conseguida através de alta coesão e baixo acoplamento. Novamente, é bem importante isso. A coesão, um módulo é coeso, se realiza uma única tarefa. O acoplamento, é uma medida de interconexão entre os módulos. Agora, a independência funcional, é conseguida através de alta coesão e baixo acoplamento. O roteiro dessa aula, então a gente está falando de modelos de projeto, vamos falar de dados, arquitetura, interface e componente. Modelos de projeto de dados, ele define a estrutura de dados que será utilizada no sistema. Como isso acontece? Através do diagrama de classes, classes de modelo ou classes de entidade, iniciada do modelo de análise, fazer agora o detalhamento. Você, então, define o conteúdo de cada objeto de dado e busca a alta coesão. Também, você define a visibilidade de objetos, de componentes e você busca um baixo acoplamento. E por fim, quando aplicado, detalhar também o modelo de entidade e relacionamento. Modelos de projetos arquiteturais, são estilos arquiteturais, nós temos então cinco. Arquitetura centrada nos dados, arquitetura de fluxo de dados, arquitetura de camada e retorno, arquitetura orientada a objetos e arquitetura em camadas. Independente do estilo arquitetural escolhido, usar um ou várias arquiteturas que se possuem, possuam independência funcional. Novamente, quando se fala em independência funcional, a gente está falando em alta coesão e baixo acoplamento. Ok? Agora, a gente vai falar aqui no exemplo de estilo arquitetural de software centrado nos dados. Então, você tem um desenho do sistema no centro e ele tem depois seis módulos que são ligados a esse sistema central, que na verdade é o banco de dados. Ou seja, você tem seis módulos ligados ao banco de dados. Cada módulo independente se conecta diretamente ao banco de dados. Esse é o estilo arquitetural. Pode ser bom em uma situação, mas em outras não. Exemplo, segurança. Cada módulo irá acessar o banco de dados e isso é ruim para a segurança. Portanto, a solução seria criar um único módulo para fazer essa consulta ao banco de dados e se conectar aos demais módulos. Exemplo de estilo arquitetural de software de fluxo de dados. Nesse exemplo, nós temos então um módulo que se ramifica em dois. O primeiro ramificado se chama filtro, processo de dados, que se liga a um único módulo. O outro módulo que foi ramificado, ele seqüencia para um próximo módulo que se une ao mesmo módulo que o filtro de processo de dados se conectou. Ok? Bom, nós temos o exemplo de estilo arquitetural de software de camada e retorno. Isso aqui parece um organograma, tendo o programa principal em cima e ele se ramifica em três outros módulos, que seria entrada, processamento e saída. Cada um desses módulos, entrada, processamento e saída, se ramifica em outros dois módulos e, dentre os dois módulos ramificados, ele se ramifica em mais dois, não todos, mas somente um, o terceiro nível. O primeiro nível é o programa principal, depois tem o segundo nível, que ele se ramificou em entrada, processo e saída, com três módulos. O terceiro nível seria então dois módulos para cada um, dois para a entrada, dois para o processamento e dois para a saída, que foram ramificados. E, por fim, o quarto módulo, na verdade, é um só módulo do terceiro se ramifica em dois. E aqui é possível enxergar o IDES-0, que é esse que é o organograma, o estilo arquitetural de software de camada e retorno. Então, esse camada e retorno, ele lembra um organograma. O estilo arquitetural de software orientado a objetos e mapa de componentes. Então, a gente tem aqui dois módulos, vamos dizer assim, você tem um módulo conta e um módulo cliente. No módulo conta, você tem, então, uma primeira caixinha dizendo conta, entidade conta, e você tem dois outros, depois, contas ramificadas, duas caixinhas filhas ramificadas, que seriam as contas filhas, que seria a conta corrente que é ligado à conta e conta de investimento ligado à conta. Então, todo esse módulo é fechado, ok? Essa conta, que seria a entidade conta, ela é ligada à entidade correntista, que é em outro módulo. Essa entidade correntista, ela tem duas caixinhas ramificadas embaixo, que são ligadas a ela por um acerto. Uma é pessoa física e outra pessoa jurídica. Então, também é um módulo apartado. E esses dois módulos são conectados pelas entidades máximas, que é conta e correntista, ok? Importante que essa, quando a gente fala na conta, que são ramificadas em conta corrente e conta investimento, na verdade, a seta é ligada a ela e não ela liga as duas caixinhas. E isso se chama herança, né? Então, toda vez que se tem uma herança, você pode fazer um agrupamento nesse componente. Importante deixar claro aqui que esse modelo de mapa de componentes, que é orientado a objetos, ele tem um baixo acoplamento, ou seja, baixa dependência entre os módulos. E essa estrutura possui uma independência funcional, ou seja, alta coesão, pois o módulo de conta só trabalha com conta e o módulo de cliente só trabalha com o cliente. Agora, vamos para o exemplo de estilo arquitetural e software em camadas. Esse estilo de modelo, ele tem três camadas, né? Modelo em três camadas. A primeira camada é a view, que é a camada de apresentação. A segunda camada é a camada de negócio, que é a control. E a terceira camada é a camada de dados, que é o model. Então, a gente tem o VCM, o modelo VCM, que é o View, Control e Model, ok? Ou arquitetura MVC, na verdade. Arquitetura MVC, não VCM. Seria o mais clássico que tem, né? Então, essa classe de controle, ela vai instanciar uma interface gráfica, que pode ser implementada numa classe de camada View e também pode instanciar em classes de modelo. Então, é bem simples. O professor aqui apresentou o controller. O controller é ligado ao View por uma seta e ao Model por outra seta, ou seja, uma ramificação. E o View é conectado ao Model, que também é conectado ao View. O Model é o View por sua vez. Então, um diagrama simples, exemplificando aí a relação entre Model, View e Controller. E as linhas sólidas indicam associação direta e as tracejadas, que é do Model para o View, indicam uma associação indireta. Modelos de interface. Então, ele define um mapa de navegação entre as interfaces gráficas do sistema, dois, a interface entre os componentes de software e três, a interface em um componente. Então, ou seja, a interface de comunicação dentro de cada componente, essa interface em um componente. Modelos de projetos ao nível de componente. Define as estruturas de dados, algoritmos, características de interface e mecanismos de comunicação alocados a cada componente de software. É a última fase de documentação antes do código. Assim, toda a informação para o programador deve estar descrita. Aqui você pega cada componente e vai detalhar tudo. Só não pode colocar o código na especificação, porque aí você estará codificando, mas é preciso descrever os algoritmos psicocódigo, pseudocódigos e fluxograma. Agora, a gente vai falar da especificação de componente de software, que é o ERS. Especificação de software, o ES, e o R é o requisito. Então, a especificação de requisitos de software, ERS. Prática recomendada, IEEE 830. A gente tem aqui um modelo simplificado para especificar um componente. O que tem que ter que conter essa especificação de componente de software? Que é a especificação do requisito de software. Tem que ter o nome do componente, tem que ter a descrição, tem que ter as classes, se são os atributos, os métodos, a assinatura, dentro dos métodos assinatura, algoritmo, e no algoritmo o fluxograma, e o diagrama de atividades, o pseudocódigo, o OCL e etc. 4. Um modelo de entidade relacionamento também tem que fazer parte desse modelo. 5. Interface entre componentes. Para cada componente irá se detalhar tudo. 6. Interface gráfica. 7. Especificação de teste, e um 8 ou etc. Então, ou seja, se um programador estiver com esse documento em mãos, não terá nenhuma dúvida de como implementar este componente. Então, a gente tem as referências aqui a respeito desta aula. O professor, então, ele entra aqui num case, um exercício de trabalho em uma clínica médica. 5. Com a chegada de um paciente, um provável paciente dirige-se à enfermaria, que se identifica na portaria, se identifica lhe dizendo o seu nome, o número de algum documento. 6. A enfermeira verifica se o paciente já é atendido por uma consulta em alguma data anterior. 7. Caso seja constatado que o paciente nunca foi atendido na clínica, ele fornece informações pessoais à enfermeira que efetua o seu cadastramento. Então, após este passo, o paciente está apto a marcar uma consulta, caso seja do seu interesse. Então, a enfermeira precisa se organizar e identificar uma data e um horário em que a consulta pode ser marcada. Então, o paciente, então, está apto a entrar na sala do médico, que previamente imune-se de informações do paciente pelo prontuário. E agora, o paciente precisa esboçar ao médico todos os sintomas, problemas e restrições que o levaram à clínica. Então, o médico avalia essas informações de saúde do paciente e efetua um diagnóstico, que pode ser seguido por um pedido de exame, além de um receituário de medicamentos, além da indicação de um retorno. Então, ao sair da sala do médico, o paciente precisa informar a enfermeira os dados de pagamento, que podem ser feitos em dinheiro ou por algum convênio. Então, aqui a gente tem destacados as palavras paciente, enfermeira, consulta, cadastramento, médico, prontuário, clínica, diagnóstico, medicamentos, exame, pagamento, convênio. Por quê? Todas essas palavras serão utilizadas num diagrama de classes. Então, você vai ter o diagrama convênio, prontuário, que pode ser conectado ao paciente, enfim, e tem vários outros diagramas. O diagrama diagnóstico, ou seja, o módulo, o consulta, exame, medicamento, pagamento, médico e enfermaria. Então, eles são conectados um ao outro, obviamente, por grau de relacionamento, de afinidade entre um módulo e outro. E como separar esse diagrama em componentes? Aqui tem dez componentes, cada classe é um componente e isso é ruim, pois o custo de integração será alto e não possui uma independência funcional. Para melhorar, pode-se, por exemplo, criar um componente pessoa, que aí você tem lá dentro o paciente, a enfermeira e médico e por aí vai. Isso vai sendo feito um melhor modelo de diagramas de classes para se chegar num sistema melhor. Então, aqui tem um primeiro modelo que o professor demonstra, que ele faz um módulo entre paciente, enfermeira e médico e um outro módulo diagnóstico, exame, medicamento. No segundo modelo, ele faz então o pessoa, que é paciente, enfermeira e médico, depois o outro componente, que é o diagnóstico, medicamento e exame e, por fim, ele vai fazendo modelos, modelo 3, modelo 4, até chegar no modelo que ele entende que é o ideal, que é o modelo 4. Aqui algumas informações adicionais. Ele tem aqui um mapa de componentes, região de custo mínimo, ele entra nesse detalhe novamente, falando de coesão e acoplamento. Aqui tem alguns modelos, você tem um modelo de grafos, que são vários modelos interligados entre o módulo e aí, para não ter todo mundo se falando com todo mundo, ele passa, então, um risco para que os módulos se conectem a esse risco. É uma camada, que ele chama, de comunicação reta por meio do desenho. E um outro, que é aquele de banco de dados, que todos os módulos se conectam a ele no centro. Então, ele faz tipo um círculo em volta desse banco de dados, que ele também chama isso de uma camada de comunicação, onde todos os componentes, os módulos, então, eles entram em contato com essa camada de comunicação, ao invés de todos se conectarem dentro do banco de dados e gerarem esse risco. E aí, ele fala depois do estereótipo de classe de interface, estereótipo de classe de controle e estereótipo de classe de modelo. E aqui, ele tem um modelo de consulta de extrato, de conta corrente, na última camada, que é a camada view, que é onde o cliente vai fazer a consulta do extrato e o saque, aí ele consulta a segunda camada, essa camada view, que é a camada de controle, onde você tem ali o cadastro da conta, o extrato e o cadastro do cliente e, por fim, a camada mais interna, que é a camada model, o modelo, onde você tem a conta e a pessoa, a unida pessoa, onde você tem lá a conta, a conta corrente e poupança, que tem aquela herança e também a herança de pessoa, que é a pessoa física e jurídica conectado. Então, o exemplo que ele deu nas aulas dele. Na sequência, o professor, ele mostra as anotações realizadas em sala de aula como diagrama de sequências. Esse diagrama de sequências é uma sequência de linhas de código, que se deve implementar para o saque, porque ele está falando do mesmo processo do saque, da mesma forma que ele fez lá no view, no controle e no modelo. Então, esse diagrama aqui, ele tem, por exemplo, PF, ele tem uma linha embaixo, que ele coloca ali, inserir cartão, é como se fosse um fluxograma isso. Depois, validar cartão, depois consulta a pessoa física, aí depois vai para a linha de baixo, inserir senha, validar senha, consultar senha, aí na linha de baixo, sacar mil, validar saque e realizar saque. É isso que é o diagrama de sequências. Contextualização desta aula, então. Agora a gente vai falar aqui, aliás, nós falamos, né, de projeto mapa de componentes final da IRS, que é a especificação dos requisitos de sistema detalhado, e aqui se especificou tudo para a implementação. Ok? Então, com isso, nós finalizamos a aula 5.