Archive for April, 2006
Resumo da aula 13 – Versão 2.0
Essa aula foi no laboratório… Vimos um tutorial da Borland, onde tinham perguntas sobre a matéria. Este tutorial é indicado pelo professor Julio, em seu blog sobre UML(1) no dia 19/04/2006. O professor Julio ficou tirando dúvidas durante a aula…
Observação Importante: Perguntas parecidas com as do tutorial da Borland estarão na prova!
Autor: Fabrine Pereira
Data: 20/04/06
Resumo da aula 12 – Versão 2.0
UML:
- Caso de uso
- Fluxo de dados
- Diagrama de classes — É mais parecido com uma rede.
SADT:
- Decomposição
- Modularização
- Modelos, análise e desenho — Especificação diferente de requisitos.
- Não tem a idéia de fluxo, como é o ponto principal do DFD.
Processo de decomposição em diagramas do tipo DFD (Diagrama de Fluxo de Dados):
- No diagrama DFD tem um diagrama inicial chamado de diagrama de contexto (Não vê o contexto como um todo, só tem o conceito de entradas transformadas em saídas). Portanto o DFD expõe claramente o conceito de contexto.
- DFD é uma linguagem simples.
- DFD é orientada a fluxo.
- DFD tem o conceito de hierarquia (decomposição).
Observação Importante: O DFD não é uma sub-linguagem da UML, mas pelas quatro razões acima, vimos que o DFD tem uma visão importante sobre fluxo de dados.
Diagrama de contexo:
Diagrama de nível 0 (ou diagrama de contexto) é o local em que as informações, sobre entradas e saídas, se encontram (já que são fornecidadas ou se destinam à entidades externas).
Autor: Fabrine Pereira
Data: 18/04/06
Resumo da aula 11 – Versão 2.0
SADT (STRUCTURED ANALISIS E DESIGN TECNIQUE)
É uma tecnica para construções de modelos. Cada modelo deve ter um objetivo e um ponto de vista. Existem duas perspectivas de modelos:
- Processo (Actigrama)
- Dados (Datagrama)
Os modelos são construidos segundo os princípios de decomposição.
A decoposição segue a norma da disciplina [3 ; 6].
Visões aplicadas ao modelo pescar:
Visão de processos:
Preparar ————– Adquirir ————– Locomover
Visão de dados:
Equipamento ———— Isca ———— Veículo
SADT é uma possibilidade que permite comparar as duas perspectivas.
Qual o objetivo?
Atingir um maior universo.
Faça o modelo de processos descanse dois dias e faça o modelo de daods e depois compare os dois. Esse método é ótimo sob o ponto de vista da qualidade, mas tem um custo muito grande.
A folha de SADT segue as regras dadas na aula 03.
Autores: Fabrine Pereira
Data: 11/04/06
Resumo da aula 10 – Versão 2.0
Tecnologia geral de sistemas (TGS), Objeto e aspectos:
– U (União) –> Conhecimentos de varias áreas
- Descartes (Especialização)
- Realistica
- Decomposição (Hierarquia)
Sistema é um conjunto de partes relacionadas para atingir um objetivo.
Características básicas:
- Objetividade (propósito)
- Entropia <– Tempo
- Homeostazia = Tende a se adaptar
- Globalidade
Conceitos:
- Sist/Subs
- Todo sistema é um sub-sistema de um sistema maior (condição parada universo).
Dividir para conquistar:
Sistemas complexos são divididos em partes. Existem conexões n(n-1) / 2 (número máximo possível de interconexões) para ligar as partes do sistema.
Qual a solução para o número de interconexões?
Seria aplicar a ideia de hierarquia! A decomposição hierárquica (princípio da TGS).
Mas para dividir o sistema em partes é preciso saber muito sobre as partes e como relaciona-las.
Acoplamento forte e fraco:
- Forte:
Acoplamento de partes, como funções, componentes e módulos que se comunicam. É quando é passado controles ou estrutura de dados complexas ou áreas comuns de dados.
O acoplamento forte deve ser evitado, pois não se pode dividir dados em uma área de memória comum.
- Fraco:
Acoplamento de dados.
Dois módulos distintos precisam passar dados (parametros ou controles). Qual a melhor maneira?
Seria a coesão forte. A coesão forte é funcional. Cada componete faz uma coisa e apenas uma única coisa (coesão funcional).
TGS é fundametal, pois vivemos dividindo sistemas complexos, mas de maneira organizada.
Information hiding é um conceito de modularização e tem a ver com a idéia de coesão.
Um agente não fala para outro agente oque sabe. Pois se um agente for capturado existem poucas possibilidades do outro ser capturado.
Publique a interface, mas não publique o seu conteúdo.
Modularização é a aplicação do TGS.
Autores: Fabrine Pereira
Data: 06/04/06
Resumo da aula 09 – Versão 1.0
Multitude de opiniões
Conceitos que foram relembrados:
- Universo de Informações — É tudo que rodeia o software a ser desenvolvido, todas as informações e situações que devem ser conhecidas para o processo de produção.
- Partes do Processo de Desenvolvimento de um Software — <definição, desenho, implantação>.
Como lidar com a complexidade de diferentes contextos durante a produção de software?
- A definição do software sempre está relacionada à implantação de outro artefato, que eventualmente pode ainda não estar implantado ou terminado. Artigo da Professora Mary Lou Maher.
- Diferentes atores do universo de informação podem ter opiniões diferentes sobre constituintes do universo de informações (processo de engenharia de requisitos). Artigo “Viewpoints on Viewpoints”.
- Os desenvolvedores de software podem escolher qual o conjunto de métodos, técnicas e ferramentas querem utilizar no processo de produção.
Estratégias para aquisição de conhecimento (elicitação de requisitos):
- Entrevistas:
Podem ser estruturadas ou simplesmente elucidativas. Sempre com o relacionamento de “um para um”.
- Reuniões:
O ponto principal da reunião é que ela pode ser n para m e permite a discussão de idéias, podendo até ser geradora de idéias como a técnica “braisntorming”.
- Leitura de Documentos:
Possibilita ao Engenheiro de Software dispor de um agente responsável pela leitura e extração de conhecimentos importantes dos documentos.
- Observação
- Questionários
- Etnografia:
A etnografia prega que o engenheiro de software/engenheiro de requisitos “viva” no UdI e reporte sua experiência de maneira que respeite os princípios culturais do UdI.
- Reutilização
- Análise de Protocolos
- Participação dos Clientes/Usuários
Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira
Data: 04/04/06