Resumo da aula 18

Apresentação final do primeiro trabalho de PES.

Resumo da aula 17

Apresentação parcial do primeiro trabalho de PES.

Resumo da aula 16

Arquitetura

             Uma observação pertinente a respeito da conexão de componentes é como projetaremos essa interface. Se a fizermos específica para o projeto em questão, estaremos bloqueando um reuso desse componente em projetos futuros. Surge então a idéia de fazer uma interface mais genérica, a qual acoplaremos um conector que fará a ligação entre os dois componentes em questão. Assim, facilita-se o reuso do componente a um custo baixo para implementar um conector. Contudo, deve-se ter em mente que, caso o componente seja muito genérico, o custo para implementar um conector irá aumentar, dificultando o reuso do componente.

             Desse impasse surge um mantra da engenharia de software: “nem 8, nem 80: 44”. Não só uma recomendação de bom senso diante da realidade, é um chamado à se ter cuidado ao se escolher quão específica será a interface de um componente implementado.

  Micro-arquitetura

             Um livro fundamental para o estudo de micro-arquitetura é “Design Patterns”, dos autores Gamma, Helm, Johnson e Vlissides (a.k.a. The Gang of Four). Seu enfoque maior é a respeito de reuso de elementos em softwares implementados sob Orientação a Objeto. Assim, ele pretende sugerir design patterns que facilitem e aumentem a qualidade do software sendo implementado.

              Para que cada padrão sugerido seja bem definido, os autores sugerem que cada padrão seja descrito a respeito dos seguintes atributos:

• Objetivo
• Sinônimo
• Motivação
• Aplicabilidade
• Estrutura
• Participante
• Colaboração
• Consequência
• Implementação

            Esse número de atributos para descrever um único padrão pretende evitar as falhas existentes na descrição em linguagem natural do mesmo.

Resumo da aula 15

Arquitetura 

            A preocupação de um arquiteto de software se concentra no próprio design do que será implementado. Assim, o arquiteto tentará projetar como os diversos módulos deverão interagir entre si para garantir o bom funcionamento e a qualidade do software desenvolvido. 

            Macro-arquitetura 

            Alguns exemplos de padrões para macro-arquitetura de software:

• Pipelines & filters: Projeta-se o software como composto por diversos estágios. O tratamento que as entradas receberão começará em um desses estágios e seguirá pelos demais estágios, um após o outro, até que as entradas tenham recebido o tratamento correto, tornando-se, assim, saída.
• Layers: Software concebido como composto por diversas camadas de círculos concêntricos, onde a troca de informação só é feita por círculos adjacentes através de uma interface bem definida.
• Blackboard: Projeta-se um espaço de memória centralizado onde todos os demais módulos poderão armazenar e retirar informações, possibilitando-se, assim, a comunicação entre eles, mas com um espaço bem definido onde isso pode acontecer.

Resumo da aula 14

SADT            

            O SADT (Structured Analysis Design Technique) vem a ser uma linguagem de modelagem que se inspira em duas teorias: TGS (Teoria Geral dos Sistemas – “todo sistema é um sub-sistema de outro”) e Cibernética (ciência do controle).  

            A ênfase maior do SADT é na perspectiva do processo, isto é, na representação por actigramas (mas possui também uma representação que enfatiza os dados, por datagramas). Um elemento será representando, então, por um pequeno retângulo que conterá setas representando informações em cada uma de suas arestas. Setas à esquerda representarão “entradas”. À direita “saídas”. Embaixo setas que representam “mecanismos” e em cima “controle” (funciona como um feedback, como indicado pela Cibernética). De todas essas setas, um elemento tem como obrigatório possuir apenas “saída” e “controle”. Assim como no DFD, SADT possui diversos níveis que também deverão obedecer ao mantra “tudo o que entra, entra; tudo o que sai, sai”.

             Por aumentar o número de categorias que uma seta por pertencer, SADT acaba possuindo uma maior granularidade que DFD. Além disso, tem uma visão de relacionamento entre as partes, em oposição à visão de fluxo que DFD propõe.

Resumo da aula 13

            “Quality is job one”. Esse é um mantra que pretende traduzir a maior preocupação ao se desenvolver um software. A qualidade como guia para o desenvolvimento pode ser verificada nas três etapas principais de desenvolvimento: Definição, Arquitetura e Implementação. 

            Uma vez que essas etapas foram cumpridas, passa-se à etapa de produção de software. Esta etapa se resume à cópia e embalagem do produto, tendo assim seu custo considerado quase que insignificante diante dos custos da etapa de desenvolvimento. 

            Sobre a conferência de Engenharia de Requisitos destacamos os seguintes pontos:

• Uma boa gerência de requisitos é parte fundamental do processo de desenvolvimento de software.
• Não só isso, mas uma maior proximidade entre as equipes de requisitos e a equipe de testes pode facilitar imensamente o desenvolvimento do software, aumentando, também, sua eficácia.
• Colocar rastros relacionando código, modelo e requisitos é fundamental quando se quer aumentar a qualidade e facilitar a manutenção do sistema, aumentando a abrangência dos testes realizados. A rastreabilidade facilita ainda uma boa análise de riscos e de impacto do sistema.

 

Alguns termos importantes:

• SGBD: Sistema de gerenciamento de banco de dados.
• Data warehousing: Extração e armazenamento de informações em banco de dados com uma característica multi-dimensional: a dimensão temporal adicionada permite uma análise histórica para fins estatísticos.
• Customer Relationship Manager: Software para a área de relacionamento com os clientes.
• Enterprise Resource Planning: Software para a área de controle interno de produção, custos, etc.

Resumo da aula 12

                        Nessa aula continuou-se a apresentar outras maneiras de se realizar a modelagem de um sistema. O processo apresentado foi o DFD (Diagramas de Fluxo de Dados). Como o próprio nome indica, o foco dessa representação está no fluxo entre as diversas partes de um sistema. Por essa abordagem, é mais intuitivo relacioná-lo à Teoria Geral dos Sistemas do que, por exemplo, à uma abordagem mais Orientada a Objetos (que fica mais à vontade com UML, por exemplo).

                        O DFD propõe 3 representações diferentes para um elemento. Um retângulo representa uma entidade externa ao sistema, um círculo um sub-sistema e setas indicam o relacionamento entre os componentes (o fluxo).

                        Ainda, nessa tentativa de se especificar um sistema usando DFD, vemos que o DFD se apresenta sempre como um diagrama de contexto. Isto é, para modelar adequadamente um sistema, constrói-se diagramas relacionados ao contexto em um certo nível. No DFD de nível 0 (zero), por exemplo, tem-se o sistema como um único componente e, a partir dele, todos os relacionamentos com entidades externas. Ao se passar para o DFD de um nível superior, vai-se destrinchando o sistema em seus módulos, seus componentes. Lembrando sempre o mantra: “Tudo que entra, entra; tudo o que sai; sai”. Ou seja, os relacionamentos que existiam num certo nível de DFD devem ser mantidos no nível seguinte, mantendo também sua orientação. E é devido à esse comportamento de ir especificando cada vez mais um sistema (quase como uma estratégia de ‘divisão e conquista’) que o DFD é facilmente associado à Teoria Geral dos Sistemas.

                        Enfim, o DFD se mostrou uma técnica simples para modelar um sistema quando se pretende ter uma clara noção do que se pretende, assim como detectar erros previamente.

Resumo da aula 11

Diagrama de Sequência 

            Este diagrama tenta descrever as interações entre os diversos módulos ao longo de uma linha do tempo. Cada módulo tem sua própria linha vertical onde estarão representados o tempo de vida dos objetos. Setas horizontais entre as linhas dos módulos indicam chamadas entre os mesmos. Assim, pode-se rastrear toda a sequência de chamadas e execução de cada módulo no cenário que se quer modelar, mantendo-se a ordem em que isso ocorre. 

Diagrama de Colaboração 

            Este diagrama irá se concentrar mais no papel dos objetos, mas sem perder a preocupação com a ordem em que as interações entre os objetos irá ocorrer. Os objetos (representados por retângulos) interagem através de mensagens (representadas através de setas) que são identificadas por números. Assim, esses números poderão traduzir a sequência em que as interações entre os diversos objetos modelados irão ocorrer. 

 

Diagrama de Transição de Estados 

            Um diagrama similar ao utilizado para representar máquina de estados, esse diagrama pretende representar todos os estados que um objeto pode vir a assumir, assim como as circunstâncias que o levarão à mudança em questão. Isso possibilita ter claro o ciclo de vida que um objeto pode vir a ter. Os estados inicial (círculo) e final (círculo com outro em volta) possuem uma representação diferenciada dos demais estados (retângulos). As transações entre os estados são representadas, como era intuitivamente esperado, por setas.

Resumo da aula 10

UML

A UML (Unified Modeling Language) provê ferramentas de modelagem amplamente usadas no desenvolvimento e documentação de um software. Dentre essas ferramentas podemos citar:

Diagramas de casos de uso:

Componentes principais:

·        Ator – É quem estimula ou é estimulado pelo sistema

·        Caso de uso – É uma ação realizada pelo sistema. Durante a criação do diagrama é utilizado um verbo no infinitivo para descrever esta ação.

Podemos ter como componentes secundários: Limites do sistema, Generalização, Inclusão e Extensão.

Diagrama de classes:

Este é o diagrama responsável por definir as classes e a relação entre elas. Uma classe é definida a partir dos seguintes parâmetros:

·        Nome

·        Atributos

·        Método

·        Superclasse

As relações mais comuns no diagrama são:

Composição – Definida por uma seta aberta e significa a relação “tem-um” entre as classes.

Herança – Definida por uma seta fechada e significa a relação “é-um” entre as classes.

Também podemos encontrar nessa modelagem relações como:

Agregação – Definida por uma linha com um losango em sua ponta e representa a relação de composição múltipla. Ou seja, uma classe possui uma coleção da outra.

Resumo da aula 09

Orientação a objetos

Paradigma comumente utilizado no desenvolvimento de software na atualidade. Consiste em composição e herança.

Objetos são criados a partir de uma classe existente no projeto. Uma classe é uma entidade que descreve atributos e métodos que podem ser realizadas pelo objeto.

Atributos

Elementos capazes de guardar um estado da natureza do seu tipo. Exemplo: Um boolean é capaz de guardar apenas os valores {true, false}, mas já um int é capaz de guardar valores entre 2^-16 até 2¹⁶. Não esquecendo que um atributo não se limita a tipos primitivos como citados, mas também a outros objetos, desde que sua classe seja conhecida.

Métodos

Estas são as ações que podem ser realizadas por um determinado objeto. Qualquer método não-estático (não me aprofundarei na explicação destes) têm acesso aos atributos da classe, que possuem valores definidos para uma instância da classe, ou seja, para um objeto.