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).
Wednesday, September 20, 2006
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.
Subscribe to:
Posts (Atom)