AULA 16

DESIGN PATTERNS

Foi comentado novamente sobre a gangue dos 4. Que foi visto na aula passada. O assusto de arquitetura de sofware foi retomado. Mas enfatizando o problema de acoplamento. A aula se resumiu em acoplamento forte e fraco.

O interessante de fazer um acoplamento fraco é que o software se torna mais maleável. Podendo reaproveitar módulos do software para reutilização. Pondendo assim se utilizado num projeto futuro. Economizando tempo e dinheiro.

Foi feita a comparação entre Lego e Quebra-cabeças. O Lego tem n possibilidades de encaixe enquanto o Quebra-cabeça só tem uma. Uma forma de ilustrar o que já foi dito a cima.

A independência dos componentes custa caro e leva tempo. Mas a possibilidade de reúso, paga os prejuízos da produção.


O livro da gangue dos 4 mostra padrões que devem ser seguidos para contruir visando reutilização.

Todo modelo deve ter :

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

AULA 15

ARQUITETURA

Começamos a falar sobre a Microsoft especificamente de Bill Gates. Ele fala que é o Arquiteto chefe da Microsoft em vez de dono. Isso porque ele queria mostrar a importância da arquitetura de software, presente em sua empresa. O arquiteto se preocupa com a melhor forma de ser implementado o software. Como será a interação entre as partes.

O livro Software Design Patterns, da gangue dos 4 é adotado como bíblia pelos defensores do OO.


Falamos sobre Macro-Arquitetura e foram mostrados alguns exemplos :

Tubos & Filtros --> É parecido com DFD em que a saída de um estágio e seguido pela entrada de outro estágio em forma de cascata.

Camadas --> O diagrama é visto como diversas camadas de círculos concêntricos. A informação passa pelos círculos adjacentes com as camadas anteriores através de mensagens.

BlackBoard --> É um espaço de memória centralizado. Onde todos os outros módulos interagem armazenando ou retirando informação dessa memória central. Existe a desvantagem do acoplamento forte.

Orientação a Objetos --> Muito conhecido em arquitetura de software e já comentado em aulas passadas.

AULA 14

Assunto da aula: SADT

SADT ==> Structured Analysis Design Technique

O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de desenvolvimento de uma linguagem estruturada para programação de máquinas-ferramenta, no MIT, no fim da década de 60 (MARCA & MACGOWAN, 1988). Este formalismo trazia algumas características revolucionárias que auxiliaram sobremaneira a descrição e desenvolvimento dos sistemas de software complexos que começavam a aparecer. São elas a decomposição funcional e o fato de serem baseados numa representação esquemática simples (VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo e também o seu desenvolvimento em direção a abordagens estruturadas completas destinadas a diferentes aplicações, principalmente para a análise de sistemas.

O SADT é baseado num diagrama conhecido como “actigrama”. Este diagrama é composto por “caixas” que representam as atividades. Estas caixas são ligadas por linhas e dispostas tal a formar uma ordem de condução das atividades seguindo da esquerda para a direita. As linhas que chegam e saem na lateral das caixas representam inputs e outputs de informação. As que chegam no topo são controles e embaixo mecanismos. Com mais algumas poucas regras além das aqui apresentadas tem-se todo o formalismo necessário para descrever estes modelos.

Por sua simplicidade e facilidade de uso (existência de ferramentas computacionais para auxílio da modelagem) o SADT é uma das principais ferramenta de modelagem de empresa(VERNADAT, 1996; CANTAMESSA & PAOLUCCI, 1998). Uma ferramenta que traz consigo grandes desvantagens. Segundo VERNADAT(1996) possuem semântica imprecisa, não provê com clareza o comportamento dinâmico do sistema, não manipula fluxos mas dependências entre as atividades, a modelagem de informações é limitada e baixa consistência devida a não integração entre os diferentes modelos. Já CANTAMESSA & PAOLUCCI (1998) aludem principalmente à necessidade de grande cuidado no desenvolvimento do modelo, alta possibilidade de desvios causados e tempo grande para a modelagem devido a necessidade excessiva de revisões para garantir a consistência do modelo.

Assim, VERNADAT(1996) sugere que esta arquitetura seria mais apropriada para modelos pequenos e restritos às visões de maior nível de abstração, portanto, com menor complexidade. Já CANTAMESSA & PAOLUCCI (1998) apresentam propostas de diversos autores para a alteração nesta arquitetura afim de saltar estes obstáculos e propõem um novo caminho complementando o formalismo SADT com com outros modelos.

Os autores desse texto são: Daniel Amaral e Henrique Rozenfeld.
Foi retirado deste link.

Na aula usamos o exemplo de um caixa eletrônico.

Objetivo: Moldar o funcionamento da caixa eletrônico.

Ponto de vista: Consumidores de caixas eletrônicos, estudantes de eng. de software.

É obrigatório ter as setas controle e saída. Senão o modelo está errado.

SADT não precisa necessáriamente de entrada. Por isso ele é melhor que o DFD.

DFD é uma visão de fluxo.
SADT é relacionamento entre partes. Decisões bem mais fundamentadas. Não tem a visão do depósito de dados.

AULA 13

Falamos sobre o primeiro trabalho que é sobre um site com login/cadastro. E como devemos usar os cenários e léxicos no trabalho.

Falamos sobre as siglas :

SGBD >> Sistema de Gerenciamento de Banco de Dados.
CRM >> Customer Relationship Management.
ERP >> Enterprise Resource Planning.

O professor falou sobre os painéis da conferência que ele foi. Em específico sobre Rastreabilidade.

Foi comentado sobre a necessidade da comunicação entre a equipe de requisitos e a de testes.

AULA 12

Nesta aula falamos sobre DFD.


DFD - > Data Flow Diagram

TGS -> Teoria Geral do sistemas , ligada a estrutura de dados( árvore ).

O.O. -> Orientação a objeto, ligada a um grafo.

É muito mais fácil trabalhar com árvore do que com gráfo.

OMT –> gerou a primeira versão da UML.

OMG –> controla os padrões da UML.


Diagrama de contexto

Mantra : "Tudo que sai, sai; Tudo que entra, entra. "

Os seus elementos são:

Setas que representam as entradas e saídas.
Círculo que representa o sistema.
Retângulo que representa entidades externas.

O nível zero serve como planejamento básico de como o sistema iterage com o ambiente.

Os níveis seguintes ao zero será mantida toda relação , porem o que se faz agora é demonstrar as relações anteriores com maiores detalhes, identificando cada subsistema. O mantra deve ser obedecido sempre.

Depósito de dados é um local de armazenamento de dados.

Veja mais sobre esse assunto neste link.

AULA 11

Toda aula foi trabalhada em cima de um exemplo. E esse foi um sistema de controle de elevador. Onde foi utilizado diversos diagramas.

Diagrama de classes

Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos.

É uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.

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 Estados

Representa os estados que um objeto pode ter e as ações necessárias para haver mudança de estados, possibililtando a visualização de um ciclo de vida do objeto.

O estado inicial é representado por um círculo preenchido enquanto o final, por um círculo preenchido envolto por outro. Estados intermerdiários são representados por retângulos e as transações de estados, por setas.

Aula 10

UML

O tópico da aula foi sobre UML (Unified Modeling Language).Projetamos um sistema de controle de elevadores, utilizando diagrama de casos de uso.

Seus componentes principais são:

Atores: aqueles quem interagem com o 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.

No exemplo dado em sala de aula :
Listamos os Atores : Pessoa( usuário ) , técnico.

Casos de uso : Chamar o elevador, ativar emergência, transportar pessoa, desligar elevador.

O diagrama de classes é responsável por definir as classes e a relação entre elas. Ela tem as seguintes características: Nome, atributos, método e superclasse.

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

Composição: É uma particularização da agregação, em que o objeto pertence a um todo.

Herança: É uma dependência entre as classes de hierarquia.

Agregação: As informações da classe precisam ser complementadas por outra classe.