Wednesday, November 22, 2006
Tuesday, November 21, 2006
Aula 24 (v.2)
Nesta aula, vimos que um gerente de projeto de software utliza-se de indicadores de produtividade para avaliar a evolução do trabalho realizado. Uma das formas de medir a produtividade de um projeto desta natureza é a taxa de número de linhas de código geradas por dia, por cada programador que faz parte da equipe de projeto. Este indicador (LOC) é o mais utilizado atualmente. Como exemplos temos:
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
Aula 23
A arquitetura sob ótica de reuso foi discutida nesta aula. Novamente observamos que quanto mais trabalho é desprendido durante a codificação, através de preocupação com flexibilidade, armazenamento e catalogamento, mais fácil será o re-uso do código no futuro. Ao passo que menos trabalho, preocupando-se apenas com descrições, buscas e integrações, mais difícil se torna o re-uso.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Aula 22 (v.2)
Vimos nesta aula o conceito de refatoração e os benefícios que este processo traz ao programador. Ao refatorar um código, devemos nos guiar por 3 principais regras: acoplamento, coesão e encapsulamento. Durante esta re-estruturação, as duplicidades são removidas a fim de garantir coesão, o código pode ser simplificado para facilitar o acoplamento de outros módulos e as informações que podem ocasionar falhas de segurança são encapsuladas.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Thursday, November 16, 2006
Aula 20 (v.2)
Nesta aula discutimos as principais estratégias de desenvolvimento de software através da adoção de métodos, técnicas e ferramentas (MTF's): Cascata, Prototipação, Espiral, V, RUP e XP.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Aula 17 (v.2)
Entrega do Trabalho 1
Links:
Philippe: http://pes.inf.puc-rio.br/c0311895/site/index.html
Andre:http://pes.inf.puc-rio.br/e0220628/site/index.html
Links:
Philippe: http://pes.inf.puc-rio.br/c0311895/site/index.html
Andre:http://pes.inf.puc-rio.br/e0220628/site/index.html
Wednesday, November 15, 2006
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 :
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.
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.
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.
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.
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.
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
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.
Tuesday, October 03, 2006
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.
Wednesday, September 20, 2006
Aula 9 (v.2)
Essa aula foi lecionada pelo professor Pádua, que tratou da UML (Unified Modeling Language - Linguagem de Modelagem Unificada), uma linguagem de diagramação criada pela OMG (Object Management Group - Grupo de Gerenciamento de Objeto) que fornece uma notação gráfica para sistemas orientados a objetos.
Se procurarmos em um dicionário o significado de modelo, vamos encontrar o seguinte "forma típica para reproduzir ou imitar", o que vai de encontro com o principal propósito da UML: uma forma universal de reprodução de sistemas. Esta forma é baseada em diagramas. Em aula enfatizamos 2 tipos: Diagramas de Casos de Uso e Diagramas de Classes.
Diagramas de Casos de Uso:
Um caso de uso representa uma ação, sob um ponto de vista mais abrangente, que é iniciada por um ator (não necessariamente um ser humano, mas uma entidade externa ao sistema), ao qual oferece um resultado útil, concreto e observável. Desta forma, um diagrama de caso de uso é uma representação gráfica das interações entre os atores e os casos de uso (permita-se ler "recursos") que fazem parte de um sistema.
Para produzir um diagrama de casos de uso é sugerido que primeiramente sejam identificados os atores e em seguida os casos de usos. Representamos os atores por "bonequinhos de pauzinho" (aqueles primeiros modelos de pessoas que desenhávamos quando crianças) e os casos de usos por seus nomes (verbo + substantivo), cada um envolto por uma elipse. A última etapa consiste em conectar os atores aos casos de usos através de linhas.
Diagramas de Classes:
Uma classe (para fins de orientação a objetos) é uma entidade que agrupa objetos de características similares, lhes definindo atributos e métodos. Em um sistema composto por mais de uma classe, é interessante visualizarmos o relacionamento entre elas, e este é o objetivo dos diagramas de classes.
Em UML uma classe é representada graficamente por uma tabela de apenas uma coluna e três linhas. Na primeira escrevemos seu nome, na segunda seus atributos e na terceira os seus métodos. As classes podem se relacionar de três maneiras distintas: através de uma associação, uma agregação ou uma generalização.
Uma associação pode ser unária, binária ou múltipla e apresenta cardinalidade e navegação. É representada graficamente através de uma linha que pode conter setas sólidas em suas extremidades (navegabilidade).
Uma agregação é uma associação especial em que se passa a idéia de vinculação de classes, em que uma é "parte-de" outra. Representamos por uma linha com uma rombóide na extremidade conectada à classe que tem a outra como "parte-de" si.
Finalmente, a generalização (ou especialização) está relacionada à ideia de taxinomia ("é-uma"). Graficamente é representada por uma linha com uma rombóide sólida na extremidade conectada à super-classe (classe pai).
Se procurarmos em um dicionário o significado de modelo, vamos encontrar o seguinte "forma típica para reproduzir ou imitar", o que vai de encontro com o principal propósito da UML: uma forma universal de reprodução de sistemas. Esta forma é baseada em diagramas. Em aula enfatizamos 2 tipos: Diagramas de Casos de Uso e Diagramas de Classes.
Diagramas de Casos de Uso:
Um caso de uso representa uma ação, sob um ponto de vista mais abrangente, que é iniciada por um ator (não necessariamente um ser humano, mas uma entidade externa ao sistema), ao qual oferece um resultado útil, concreto e observável. Desta forma, um diagrama de caso de uso é uma representação gráfica das interações entre os atores e os casos de uso (permita-se ler "recursos") que fazem parte de um sistema.
Para produzir um diagrama de casos de uso é sugerido que primeiramente sejam identificados os atores e em seguida os casos de usos. Representamos os atores por "bonequinhos de pauzinho" (aqueles primeiros modelos de pessoas que desenhávamos quando crianças) e os casos de usos por seus nomes (verbo + substantivo), cada um envolto por uma elipse. A última etapa consiste em conectar os atores aos casos de usos através de linhas.
Diagramas de Classes:
Uma classe (para fins de orientação a objetos) é uma entidade que agrupa objetos de características similares, lhes definindo atributos e métodos. Em um sistema composto por mais de uma classe, é interessante visualizarmos o relacionamento entre elas, e este é o objetivo dos diagramas de classes.
Em UML uma classe é representada graficamente por uma tabela de apenas uma coluna e três linhas. Na primeira escrevemos seu nome, na segunda seus atributos e na terceira os seus métodos. As classes podem se relacionar de três maneiras distintas: através de uma associação, uma agregação ou uma generalização.
Uma associação pode ser unária, binária ou múltipla e apresenta cardinalidade e navegação. É representada graficamente através de uma linha que pode conter setas sólidas em suas extremidades (navegabilidade).
Uma agregação é uma associação especial em que se passa a idéia de vinculação de classes, em que uma é "parte-de" outra. Representamos por uma linha com uma rombóide na extremidade conectada à classe que tem a outra como "parte-de" si.
Finalmente, a generalização (ou especialização) está relacionada à ideia de taxinomia ("é-uma"). Graficamente é representada por uma linha com uma rombóide sólida na extremidade conectada à super-classe (classe pai).
Monday, September 11, 2006
Aula 8 (v.2)
No início da aula nos foi fornecido um material que contém um modelo de cenários descrito através da linguagem de entidades e relacionamentos.
Em seguida percebemos a existência de triggers no modelo. Eles passam a idéia de episódios seqüências. Um episódio pode ser descrito por um cenário, que por sua vez cria a idéia de sub-cenários, o que possibilita a decomposição de cenários.
Um cenário A pode estar relacionado a um cenário B através de uma pré-condição, e a um cenário C através de uma relação pai-filho (sub-cenário). Um cenário também pode se relacionar a outro por uma exceção.
Vimos também duas estratégias de verificação: Ciclo Autor/Leitor e Ciclo de Inspeção. A primeira delas surgiu com SADT (Structure Analysis and Design Technique) e a segunda na década de 70 por Fagan, um funcionário da IBM.
No Ciclo de Inspeção (Fagan Inspection) existem quatro papéis: Moderador, Secretário, Autor e Revisor. Esta estratégia consiste em outras quatro atividades: Preparação, Leitura, Reunião e Revisão. De forma sucinta temos o autor preparando o documento, o revisor o lendo e assinalando os defeitos do documento em uma lista de itens, uma reunião para que o revisor apresente seus resultados ao autor, e ao final desta a geração de uma lista de correções. Desta forma os autores revisam o documento com base no que lhes foi apresentado pelos revisores.
Ao final da aula discutimos a Teoria Geral de Sistemas (TGS), destacando dois princípios de modelagem: as relações "parte-de" (decomposição) e "é-uma" (instanciação).
Nos foi apresentada uma grande dificuldade da orientação a objetos: a complexidade em descrever entidades da vida real em classes de objetos. Desta forma sistemas que eram criados de forma a serem re-utilizados futuramente acabaram por gerar enormes re-trabalhos, já que não houve, no início de implementações orientadas a objetos, estudos suficientes na criação de abstrações mais altas (uso de herança). Afim de conter esta situação a ótica foi voltada aos componentes. Os objetos vistos como componentes precisavam de mais uma classificação, já que tornavam-se redundates dentro de um sistema complexo. Daí a idéia de separar os aspectos dos objetos que os utilizam. Tal idéia de aspectos facilita a unificação de características que ficavam espalhadas nas classes (esta idéia foi originada pela Xerox).
Em seguida percebemos a existência de triggers no modelo. Eles passam a idéia de episódios seqüências. Um episódio pode ser descrito por um cenário, que por sua vez cria a idéia de sub-cenários, o que possibilita a decomposição de cenários.
Um cenário A pode estar relacionado a um cenário B através de uma pré-condição, e a um cenário C através de uma relação pai-filho (sub-cenário). Um cenário também pode se relacionar a outro por uma exceção.
Vimos também duas estratégias de verificação: Ciclo Autor/Leitor e Ciclo de Inspeção. A primeira delas surgiu com SADT (Structure Analysis and Design Technique) e a segunda na década de 70 por Fagan, um funcionário da IBM.
No Ciclo de Inspeção (Fagan Inspection) existem quatro papéis: Moderador, Secretário, Autor e Revisor. Esta estratégia consiste em outras quatro atividades: Preparação, Leitura, Reunião e Revisão. De forma sucinta temos o autor preparando o documento, o revisor o lendo e assinalando os defeitos do documento em uma lista de itens, uma reunião para que o revisor apresente seus resultados ao autor, e ao final desta a geração de uma lista de correções. Desta forma os autores revisam o documento com base no que lhes foi apresentado pelos revisores.
Ao final da aula discutimos a Teoria Geral de Sistemas (TGS), destacando dois princípios de modelagem: as relações "parte-de" (decomposição) e "é-uma" (instanciação).
Nos foi apresentada uma grande dificuldade da orientação a objetos: a complexidade em descrever entidades da vida real em classes de objetos. Desta forma sistemas que eram criados de forma a serem re-utilizados futuramente acabaram por gerar enormes re-trabalhos, já que não houve, no início de implementações orientadas a objetos, estudos suficientes na criação de abstrações mais altas (uso de herança). Afim de conter esta situação a ótica foi voltada aos componentes. Os objetos vistos como componentes precisavam de mais uma classificação, já que tornavam-se redundates dentro de um sistema complexo. Daí a idéia de separar os aspectos dos objetos que os utilizam. Tal idéia de aspectos facilita a unificação de características que ficavam espalhadas nas classes (esta idéia foi originada pela Xerox).
Thursday, August 31, 2006
Aula 7
A aula foi dividida em duas partes. A primeira foi sobre codificação, e a segunda, voltamos a falar dos requisitos.
Primeira parte :
Foi comentado a diferença entre Buble sort e Quick sort. O primeiro usa menos memória mas é mais lento. E o Segundo e mais rápido e usa mais memória. Cabe ao engenherio tomar a decisão correta.
Falamos sobre acoplamento fraco e a sua importância. Sobre a expressão "JUST IN TIME" e foi dado o exemplo da madereira. Se a madereira trabalha sem estoque, ela só vai poder cortar quando a matéria-prima chegar. Produz na mesma velocidade em que chega o estoque.
Logo após, foi comentado novamente sobre o conceito do Sr. Knuth sobre programação
literária. Produzir uma documentação legível e bem escrita. Utilizar também frases curtas.
Segunda Parte :
Voltando a falar de requisitos, foi ensinado como elicitar os requisitos. Como extrair as informações necessárias do cliente.
5W1H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ?
5W2H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ? Quanto custa ?
Sobre modelagem: vimos que temos que escolher uma linguagem artificial para modelarmos os requisitos. Modelar -> Analizar/Verificar -> Validação -> Retro-Alimentação ( correteza / completeza) .
Primeira parte :
Foi comentado a diferença entre Buble sort e Quick sort. O primeiro usa menos memória mas é mais lento. E o Segundo e mais rápido e usa mais memória. Cabe ao engenherio tomar a decisão correta.
Falamos sobre acoplamento fraco e a sua importância. Sobre a expressão "JUST IN TIME" e foi dado o exemplo da madereira. Se a madereira trabalha sem estoque, ela só vai poder cortar quando a matéria-prima chegar. Produz na mesma velocidade em que chega o estoque.
Logo após, foi comentado novamente sobre o conceito do Sr. Knuth sobre programação
literária. Produzir uma documentação legível e bem escrita. Utilizar também frases curtas.
Segunda Parte :
Voltando a falar de requisitos, foi ensinado como elicitar os requisitos. Como extrair as informações necessárias do cliente.
- Entrevista
- Reuniões
- Questionário
- Leitura de documentos
- Etnografia
- Observação
- Engenharia reversa
- Reutilização
- Participação do cliente
5W1H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ?
5W2H ==> O que ? Por que ? Onde ? Quando ? Quem ? Como ? Quanto custa ?
Sobre modelagem: vimos que temos que escolher uma linguagem artificial para modelarmos os requisitos. Modelar -> Analizar/Verificar -> Validação -> Retro-Alimentação ( correteza / completeza) .
Aula 6
Começamos a aula com mapeamento de decisões e árvore de decisões.
Elas ajudam a detectar erros na especificação. Também combatem a ambiguidade e servem para descobrir erros antes que eles ocorram.
Falamos sobre escopo, ele delimita a área de entendimento aonde usaremos o modelo. Aonde também estará os requisitos do projeto.
Duas frases que foram enfatizadas :
Um BOM desenho vale mais que mil palavras. Para um software ser eficaz, ele precisa atender os requisitos.
Elas ajudam a detectar erros na especificação. Também combatem a ambiguidade e servem para descobrir erros antes que eles ocorram.
Falamos sobre escopo, ele delimita a área de entendimento aonde usaremos o modelo. Aonde também estará os requisitos do projeto.
Duas frases que foram enfatizadas :
Um BOM desenho vale mais que mil palavras. Para um software ser eficaz, ele precisa atender os requisitos.
Aula 5
-= MODELOS =-
Vimos na aula o conceito de modelos. Logo no início fizemos um exercício de fluxograma, que é uma linguagem gráfica simples.
Falamos sobre as vantagens de se fazer um modelo:
- Ajudam a sair da abstração para um nível de detalhe bastante acentuado.
- Simplificam, combatem a complexidade.
- Estabelecem uma liguagem comum.
- Facilitam a sistematização.
Outras regras de bom uso:
- Acoplamento baixo.
- Coesão alta.
- Information Hiding ( Encapsulamento ).
Aula 4
== Regra 4 - Invenção de nomes ==
Escolher o nome com sapiência, para que outras pessoas consigam identificar e associar a sua função.
O nome tem que ser : Legível, Relacionado com o problema, ter prefixo.
Prós : Bom entendimento, capacidade de análise.
Capacidade de análise.
Contras: Dá muito trabalho.
Gasta mais memória.
Concluindo, vale a pena gastar um pouco mais de tempo para criar variáveis. Isso influi num bom entendimento no futuro, ou para outras pessoas que lerão seu documento.
== Regra 5 - “Small is Beautiful” ==
Faça um código simples, direto e pouco prolixo.
== Regra 6 - Como organizar seu livro diário ==
Serve para manter o registro sobre a sua propriedade e lembrar das alterações que você fez.
Foram mencionadas associações de Engenharia de Software como: SBC, IEEE, ACM.
Separar os erros por tipo: Interface, dispositivos de entrada e saída, memória, etc. .
Isso tudo está denominado no Personal Sofware Process (PSP) , para fins de facilitar o desenvolvimento do software ou documentos em geral.
Escolher o nome com sapiência, para que outras pessoas consigam identificar e associar a sua função.
O nome tem que ser : Legível, Relacionado com o problema, ter prefixo.
Prós : Bom entendimento, capacidade de análise.
Capacidade de análise.
Contras: Dá muito trabalho.
Gasta mais memória.
Concluindo, vale a pena gastar um pouco mais de tempo para criar variáveis. Isso influi num bom entendimento no futuro, ou para outras pessoas que lerão seu documento.
== Regra 5 - “Small is Beautiful” ==
Faça um código simples, direto e pouco prolixo.
== Regra 6 - Como organizar seu livro diário ==
Serve para manter o registro sobre a sua propriedade e lembrar das alterações que você fez.
Foram mencionadas associações de Engenharia de Software como: SBC, IEEE, ACM.
Separar os erros por tipo: Interface, dispositivos de entrada e saída, memória, etc. .
Isso tudo está denominado no Personal Sofware Process (PSP) , para fins de facilitar o desenvolvimento do software ou documentos em geral.
Thursday, August 17, 2006
Aula 3
Falamos novamente sobre o software C & L .
Discutimos sobre arte x artezanato.
O professor comentou sobre o livro PSP( Personal Software Process ), a bíblia do engenheiro de software para efeitos de controle de sua produtividade.
Foi dado na sala de aula 6 regras de disciplina:
1- Todo documento deve ter título, autor, data, versão, indicador de conteúdo.
2- Em todo documento deve ter pré e pós condições. ETVX (Entry-Tasks-Verification&Validation-Exit), criado pela IBM nos anos 80.
3- [ 3 ,6 ] Todo sistema é um sub-sistema de um sistema maior.
Sempre divida o sistema em 3 ou 6 partes, assim torna-se mais facil identificar o início, meio e fim do que se deseja dividir, enquanto que não torna muito complexas as interconexões entre as partes.
Douglas Ross falou: "Tudo tem início, meio e fim."
Numero mágico -> 7+- 2
A clusterização diminui a complexidade dos problemas.
Discutimos sobre arte x artezanato.
O professor comentou sobre o livro PSP( Personal Software Process ), a bíblia do engenheiro de software para efeitos de controle de sua produtividade.
Foi dado na sala de aula 6 regras de disciplina:
1- Todo documento deve ter título, autor, data, versão, indicador de conteúdo.
2- Em todo documento deve ter pré e pós condições. ETVX (Entry-Tasks-Verification&Validation-Exit), criado pela IBM nos anos 80.
3- [ 3 ,6 ] Todo sistema é um sub-sistema de um sistema maior.
Sempre divida o sistema em 3 ou 6 partes, assim torna-se mais facil identificar o início, meio e fim do que se deseja dividir, enquanto que não torna muito complexas as interconexões entre as partes.
Douglas Ross falou: "Tudo tem início, meio e fim."
Numero mágico -> 7+- 2
A clusterização diminui a complexidade dos problemas.
Aula 2
Na aula 2 foi comentado o triangulo do conhecimento.
- Engenharia de Software
- Conhecimento da plataforma
- Conhecimento do problema a ser abordado
Falamos da diferença entre eficácia e eficiência.
O professor também pediu para dar uma olhada no software C & L , uma ferramenta de edição e visualização de Cenários e Léxicos.
Também falamos sobre eficácia versus eficiência no momento do desenvolvimento de um software.
O professor comentou novamente sobre a linguagem usada em mini-computadores chamada MUMPS.
- Engenharia de Software
- Conhecimento da plataforma
- Conhecimento do problema a ser abordado
Falamos da diferença entre eficácia e eficiência.
O professor também pediu para dar uma olhada no software C & L , uma ferramenta de edição e visualização de Cenários e Léxicos.
Também falamos sobre eficácia versus eficiência no momento do desenvolvimento de um software.
O professor comentou novamente sobre a linguagem usada em mini-computadores chamada MUMPS.
Aula 1
A primeira aula foi a apresentação do curso e sobre o que será abordado.
Discutimos sobre software livre e software proprietário. As vantagens e desvantagens de um código aberto. Várias linguagens foram citadas pelo professor, entre elas Cobol, MUMPS, Fortran, Scheme.
Também foi comentado sobre a qualidade do software e seu processo de desenvolvimento.
Discutimos sobre software livre e software proprietário. As vantagens e desvantagens de um código aberto. Várias linguagens foram citadas pelo professor, entre elas Cobol, MUMPS, Fortran, Scheme.
Também foi comentado sobre a qualidade do software e seu processo de desenvolvimento.
Subscribe to:
Posts (Atom)