ENQUADRAMENTO CONCEPTUAL DE ENSINO/APRENDIZAGEM PARA O DESENVOLVIMENTO DE PROGRAMAS EDUCATIVOS

Tamanho: px
Começar a partir da página:

Download "ENQUADRAMENTO CONCEPTUAL DE ENSINO/APRENDIZAGEM PARA O DESENVOLVIMENTO DE PROGRAMAS EDUCATIVOS"

Transcrição

1 ENQUADRAMENTO CONCEPTUAL DE ENSINO/APRENDIZAGEM PARA O DESENVOLVIMENTO DE PROGRAMAS EDUCATIVOS João Carlos Lopes Batista Instituto Superior de Contabilidade e Administração de Aveiro A. Dias Figueiredo Laboratório de Informática e Sistemas Universidade de Coimbra Portugal Resumo A identificação de alguns problemas na transição entre as fases de concepção e de desenvolvimento de programas educativos conduziu-nos ao desenvolvimento de um enquadramento conceptual de ensino/aprendizagem para aplicação nessa transição. Nesse enquadramento, que designamos por modelo das três entidades, são explicitamente caracterizadas as três entidades envolvidas na utilização de um programa educativo o aluno, o educador e o programa educativo, bem como a forma como as três entidades comunicam entre si. Este modelo é explorado para a aplicação prática através de uma outra proposta, a tabela de responsabilidades estendida, que permite especificar a interacção entre as três entidades. Esta tabela é construída na transição da fase de concepção para a fase de desenvolvimento de programas educativos e conduz à utilização de métodos orientados a objectos durante o desenvolvimento. 1. Introdução As metodologias de produção de programas educativos [1, 2, 3] incluem duas fases: a fase de concepção e a fase de desenvolvimento. Na fase de concepção elabora-se um documento, designado por documento de concepção pedagógica, em que se estabelece uma definição do programa pretendido. Na segunda fase, a de desenvolvimento, é realizado o desenvolvimento do programa. O produto final das duas fases é o programa educativo. Alguns problemas impedem, em geral, que um programa assim produzido coincida com o programa pretendido. Dois desses problemas constituem a motivação para este estudo. Por um lado, a atenção e o esforço na produção de um programa educativo direccionam-se apenas para um dos três intervenien-tes no contexto de utilização do programa, que é o próprio programa educativo, não se especificando os intervenientes restantes, o aluno e o educador, nem as interacções entre os três intervenientes. Por outro lado, as dificuldades na transição entre as fases de concepção e de desenvolvimento são elevadas, o que se deve a dois factores: as técnicas utilizadas para a elaboração dos modelos das duas fases são substancialmente distintas; e a complexidade das concepções é crescente, implicando programas mais elaborados e a utilização, para o seu desenvolvimento, de métodos e técnicas mais sofisticadas. Na secção dois deste artigo propomos um enquadramento conceptual, o modelo das três entidades, em que são explicitamente caracterizadas todas as entidades envolvidas no processo de aprendizagem realizado com recurso a programas educativos, bem como a forma como as entidades comunicam entre si. Este enquadramento visa suportar a transição entre as duas fases, facilitando as actividades de desenvolvimento. A aplicação prática do modelo das três entidades é descrita ao longo da secção três, em que propomos a tabela de responsabilidades estendida e os seus elementos de notação. A modelização do enquadramento conceptual e a transição entre as duas fases são realizados com recurso ao paradigma dos objectos [4, 5]. Por fim, na secção quatro, apresentamos as conclusões e as perspectivas deste estudo. 2. Modelo das três entidades 2.1. Contexto restrito de ensino/aprendizagem Num contexto de ensino/aprendizagem em que se utilizam programas educativos encontram-se envolvidas três entidades: o aluno, o educador e o programa educativo. Em face de cada contexto concreto, o número de indivíduos de cada entidade varia. Pode tratar-se, por exemplo, de um contexto de sala de aula, em que existem vinte alunos, agrupados dois a dois. Cada grupo utiliza um computador munido de um programa educativo, e todos os alunos são orientados por um educador. No âmbito deste estudo, o contexto de ensino/aprendizagem é caracterizado de uma forma que designamos por restrita: um programa educativo, utilizado por um ou mais alunos que são orientados, em geral, por um educador. No exemplo da

2 sala de aula existem vários contextos deste tipo, em que o educador é comum. A existência deste tipo de contextos pode mesmo ser incentivada, dada a facilidade com que é praticado um ensino mais individualizado Diagrama de classes Ao estabelecer um contexto restrito de ensino/aprendizagem modeliza-se cada uma das três entidades como uma classe de indivíduos. Cada instância de uma classe é um objecto, e a comunicação entre os vários objectos realiza-se através de troca de mensagens. O modelo abstracto de um contexto deste tipo, representando as classes envolvidas, é apresentado na figura 1, com o auxílio de um diagrama de classes1. Além de representar as classes envolvidas, este diagrama de classes delimita o sistema em análise. Desta forma, e desde o início, o sistema adquire fronteiras, tornando a sua análise imune a influências externas. Figura 1 Diagrama de classes de um contexto restrito de ensino/aprendizagem Estas fronteiras permitem o estabelecimento de um princípio: todas as entidades envolvidas são caracterizadas, e o contexto de caracterização é comum a todas elas. Como a sua existência é explícita, não existe argumento para que a caracterização de cada uma das entidades não seja realizada2. Este princípio é importante porque a concepção e o desenvolvimento de programas educativos deixam de poder ser tratados isoladamente, passando a ser encarados como dizendo respeito a uma de três entidades, todas elas importantes, que devem interagir e colaborar no processo de aprendizagem dos alunos. Entre as classes Aluno e Educador pode existir um relacionamento de hereditariedade. A existência ou não desse relacionamento resulta, em particular, de cada contexto restrito de ensino/aprendizagem. Por exemplo, na concepção Dice Calculation3, as propriedades e o comportamento da classe Educador também se encontram presentes na classe Aluno. O diagrama de classes representado na figura 1 evolui então para o representado na figura 2, em que se observa que a classe Aluno é descendente, ou herdeira, da classe Educador.

3 Figura 2 Diagrama de classes de um contexto restrito de ensino/aprendizagem em que a classe Aluno é descendente da classe Educador, como indicado pela seta Este relacionamento de hereditariedade permite evidenciar a caracterização da classe Educador, por um lado, e o facto de esta não possuir, no âmbito do contexto restrito de ensino/aprendizagem, características internas ou externas que o aluno também não possua. Permite evidenciar também que, além das características do educador, o aluno possui outras Diagrama de objectos Cada instância de uma classe é um objecto. No contexto restrito de ensino/aprendizagem consideram-se objectos para cada uma das três classes, representando-se esses objectos através de um diagrama de objectos. Neste, além dos objectos, representa-se também a forma como comunicam, através de mensagens, como se pode observar na figura 3. Figura 3 Diagrama de objectos de um contexto restrito de ensino/aprendizagem em que são representados os objectos do contexto e as trocas de mensagens entre eles4 Num contexto restrito de ensino/aprendizagem existem normalmente um objecto da classe Programa_Educativo, um outro da classe Educador e um ou mais da classe Aluno. No diagrama de objectos da figura 3 são representados dois objectos da classe Aluno. Entre todos estes objectos, a comunicação é realizada através de trocas de mensagens. No âmbito deste estudo, não se caracterizam as mensagens que se processam entre os seres humanos, ou seja, entre objectos das classes Aluno e Educador. O diagrama de objectos da figura 4 ilustra o contexto restrito de ensino/aprendizagem do Dice Calculation. Neste programa são consideradas uma instância da classe Programa_Educativo, uma da classe Educador e uma ou duas da classe Aluno. No caso concreto da figura apresentada, são considerados dois jogadores.

4 Figura 4 Diagrama de objectos de um contexto restrito de ensino/aprendizagem em que é utilizado o Dice Calculation por dois alunos orientados por um educador. A comunicação entre os quatro objectos processa-se através de trocas de mensagens 2.4. Simetria na comunicação O modelo básico de comunicação que tem sido utilizado na concepção de programas educativos baseia-se num ciclo em que a uma acção do aluno corresponde uma reacção do programa, e assim sucessivamente [2]. Este modelo restringe a interacção entre os objectos presentes num contexto restrito de ensino/aprendizagem, dado que o fluxo de controlo se dirige apenas num sentido. Através das figuras 3 e 4 pode observar-se que na proposta aqui defendida as mensagens são sempre representadas nos dois sentidos, o que significa que a comunicação deve ser dialogante. Este modelo de comunicação subjacente ao modelo das três entidades é representado na figura 5. Pela sua observação verifica-se que a uma acção de um objecto, que é identificada pelo envio de uma mensagem, se segue uma reacção de outro objecto que determina a sua próxima acção, que é também identificada pelo envio de uma mensagem, e assim sucessivamente. Este modelo de comunicação é extensível a um número superior de objectos. Nessas condições, o envio de uma mensagem por parte de um objecto não tem, obrigatoriamente, de ser dirigido ao objecto do qual recebeu a última mensagem. O que permite esta evolução do modelo é o facto de a comunicação se verificar através de mensagens, e não apenas através de comandos. Com o conceito de mensagem, o diálogo torna-se explícito. Neste diálogo, o aluno deve possuir controlo, nomeadamente no que respeita à escolha do percurso de aprendizagem. No entanto, o programa educativo também possui o seu próprio controlo. A comunicação entre objectos é, assim, baseada em diálogo, e não na utilização arbitrária de algo, o programa educativo, que responde impassivelmente às ordens e aos comandos que recebe. Figura 5 Modelo de comunicação entre objectos, em que todos os objectos envolvidos são, fundamentalmente, agentes5, dado que todos enviam e recebem mensagens

5 A defesa que aqui se faz de que o programa educativo assuma a sua quota parte de responsabilidade no controlo do diálogo não deverá ser entendida como correspondendo a uma diminuição da capacidade de controlo do aluno. Pelo contrário, corresponde à previsão, no modelo, de uma interacção mais simétrica6 do programa educativo no controlo do diálogo, tendo em vista permitir ao aluno o exercício de formas superiores de controlo Mensagens implícitas e explícitas Para melhor caracterizar este modelo de comunicação entre os objectos, distinguimos dois tipos de mensagem: mensagens explícitas e mensagens implícitas7. Esta classificação é estabelecida pela forma como as mensagens são enviadas e recebidas. As mensagens explícitas distinguem-se pelo facto de serem concebidas como mensagens no sentido tradicional do termo. Assim, por exemplo, uma opção de um menu é uma mensagem explícita. É enviada explicitamente pelo programa e activada, também explicitamente, pelo utilizador. Da mesma forma, quando o Dice Calculation apresenta uma operação aritmética e pede ao aluno que apresente o resultado da operação, está a enviar uma mensagem explícita. A resposta do aluno também é uma mensagem explícita. O estado, em cada momento, da imagem transmitida por um programa educativo não se considera como mensagem explícita. No entanto, trata-se de uma mensagem, que designamos por implícita na medida em que transmite algo que provoca uma reacção por parte do aluno. Por exemplo, o deslocar da seta do rato ao longo do écrã, como reacção à acção do aluno, é uma mensagem implícita, da mesma forma que o é o deslocamento físico do rato por parte do utilizador. A utilização consciente de mensagens implícitas, como complemento às explícitas, torna mais rica a interacção entre o aluno e o educador, por um lado, e entre estes e o programa educativo, por outro. Desta forma, a efectivação da comunicação é reforçada quando se utilizam mensagens implícitas. Por exemplo, no Dice Calculation, o deslocamento do pino de um jogador ao longo do tabuleiro de jogo, que constitui uma mensagem implícita, apresenta duas consequências importantes: «183 \f "Symbol" \s 12» estabelece o estado do jogador de forma simples e clara; «183 \f "Symbol" \s 12» simplifica a comunicação da posição do jogador. Se, por exemplo, essa comunicação fosse apresentada explicitamente através da mensagem "avança 3 casas, parando na casa 32", e se não fosse representado o quadro de jogo, a comunicação seria significativamente mais complexa, menos clara e acarretaria uma diminuição da motivação do aluno. 3. Tabela de responsabilidades estendida O modelo das três entidades estabelece um enquadramento conceptual para um contexto restrito de ensino/aprendizagem em que são usados programas educativos. Não é claro, até agora, como se aplica este modelo na prática. Para isso, propomos a tabela de responsabilidades estendida, em que se caracterizam cada classe e as mensagens entre os objectos dessas classes. Propomos ainda uma notação a utilizar na construção dessa tabela Responsabilidades A tabela de responsabilidades estendida que aqui propomos é uma extensão da tabela de responsabilidades de Crossley e Green [2]. Nesta consideram-se três colunas, uma para cada classe: o aluno, o educador e o programa educativo. Em cada coluna, exprime-se quem faz o quê [2], ou seja, o conteúdo dessa tabela é relativo às acções que cada entidade toma. Crossley e Green apresentam dois outros documentos importantes: a tabela de comandos/condições, em que se exprimem as condições em que cada comando pode ser utilizado; e a tabela de comandos/reacções, em que se apresentam as reacções do programa a cada um dos seus comandos. Estas tabelas são substituídas, em [3], por um diagrama de estados. Se forem considerados todos estes documentos, verifica-se que estão expressas as funções externas de cada entidade, bem como os estados do programa educativo. A tabela de responsabilidades estendida baseia-se nessas informações e completa-as com os atributos das três classes. Obtém-se, assim, uma caracterização mais completa das três classes. Além disso, e dado que o modelo das três entidades se baseia no paradigma dos objectos, estabelece-se uma especificação da comunicação entre os objectos do contexto restrito de ensino/aprendizagem, através de mensagens explícitas e implícitas. A tabela de responsabilidades estendida apresenta-se em três colunas, uma por cada classe. Para cada uma, indica-se a sua cardinalidade, ou seja, o número de objectos de cada classe. Por exemplo, para o Dice Calculation, a cardinalidade das classes Educador e Programa_Educativo é unitária e a da classe Aluno é de um a dois.

6 3.2. Cenários Ao longo das linhas representa-se aquilo que aqui se convencionou chamar cenários, que se procuram na concepção. A divisão em cenários é uma forma de decompor o contexto em partes menores, com que se pode lidar mais facilmente. Por exemplo, no Dice Calculation, identificam-se alguns cenários como Dados, Jogador ou Operação. A figura 6 ilustra a primeira fase da elaboração da tabela de responsabilidades estendida para o contexto restrito de utilização do Dice Calculation, indicando-se todos os cenários que foram identificados através do documento de concepção. Figura 6 Primeira fase da elaboração da tabela de responsabilidades estendida, em que se apresentam as classes e as respectivas cardinalidades, bem como os cenários identificados através do documento de concepção. A decomposição em cenários é uma forma de gerir a complexidade. No entanto, é uma actividade subjectiva: se cada cenário for muito complexo, o ganho da decomposição é nulo; e se cada cenário for muito pequeno, perde-se a noção do todo. A nossa sugestão é de realizar um processo iterativo de decomposição com vista a encontrar um conjunto coerente e consistente de cenários, cada um dos quais relativamente simples. Para orientação de aplicação prática, sugerimos que a especificação completa de cada cenário não ultrapasse uma página Atributos, métodos e pedidos A fase seguinte corresponde à especificação de cada cenário. Essa especificação consiste em identificar, para cada classe, os seus atributos (A), os seus métodos (M) e os pedidos (P) que os seus objectos efectuam aos objectos das outras classes, ou seja, as mensagens que lhes enviam. Ao especificar as mensagens enviadas por cada objecto especificam-se também, implicitamente, as mensagens recebidas. No entanto, constatou-se que uma especificação cruzada, em que se procuram as mensagens enviadas e as recebidas, contribui para evitar omissões e serve para realizar verificações de consistência Diálogos Para cada cenário especificam-se também os diálogos (D) entre os objectos. Aplicam-se em situações em que as mensagens enviadas e recebidas não são perfeitamente identificáveis. Por exemplo, uma caixa de diálogo utilizada na alteração dos dígitos dos dados envolve uma situação de diálogo intenso, em que o utilizador altera sucessivamente os diversos dígitos, provocando sistematicamente reacções do programa, que se traduzem por mensagens implícitas. Verificou-se que a especificação destes diálogos é particularmente útil para situações em que existem mensagens implícitas, pelo menos por parte de um dos objectos envolvidos no diálogo.

7 Figura 7 Representação de um diálogo entre dois objectos, em que existe um fluxo intenso de trocas de mensagens Cada diálogo entre dois objectos é especificado na tabela de responsabilidades estendida através do símbolo representado na figura 7. Em geral, os identificadores dos diálogos dos dois objectos coincidem, o que serve para verificar a consistência da interacção entre ambos os objectos. No entanto, o significado do diálogo, para cada um dos objectos, é distinto. No exemplo da figura 7, o papel do objecto da classe Aluno é diverso do papel do objecto da classe Programa_Educativo. O Aluno toma decisões de alteração dos dígitos, enquanto que o Programa_Educativo reage, em conformidade, a essas decisões Exemplo Na figura 8 representa-se a especificação completa do cenário Relógio, identificado na concepção Dice Calculation. Nesta figura, «183 \f "Symbol" \s 12» as linhas a tracejado, com setas a apontar para ambos os lados, estabelecem uma correspondência de atributos de duas classes diferentes. Por exemplo, o atributo Tempo por volta é semelhante nas três classes envolvidas; «183 \f "Symbol" \s 12» as linhas cheias com seta apenas de um dos lados representam o envio de mensagens, ou seja, representam pedidos de um objecto de uma classe a um objecto de outra classe. Por exemplo, tanto o objecto da classe Aluno como o da classe Educador pedem ao objecto da classe Programa_Educativo para alterar o tempo por volta do relógio. Figura 8 Especificação do cenário Relógio identificado na concepção Dice Calculation

8 Pela observação da figura 8 constata-se ainda que: «183 \f "Symbol" \s 12» as classes Aluno e Educador não são caracterizadas, necessariamente, da mesma forma. Por exemplo, verifica-se que a classe Aluno possui o atributo Posição do ponteiro do relógio, que não é comum à classe Educador porque esta não necessita, no âmbito da concepção, de o conhecer; «183 \f "Symbol" \s 12» as classes podem possuir atributos e/ou métodos privados, ou seja, desconhecidos das outras classes. Por exemplo, a classe Programa_Educativo possui um método nessas condições, o método Avança (1/60) x tempo por volta. Deve ainda referir-se que, apesar de no exemplo da figura 8 não existirem pedidos por parte dos objectos da classe Programa_Educativo, não significa que não possam ocorrer. Ocorrem, de forma implícita, durante os diálogos. Ocorrem também, explicitamente, como ilustrado na figura 9, em que se representa um pedido do objecto da classe Programa_Educativo a um objecto da classe Aluno, no âmbito do cenário Jogada. Figura 9 Ilustração de um caso em que se verifica um pedido explícito por parte do objecto da classe Programa_Educativo Observações Finalmente apresentam-se duas observações relativas à tabela de responsabilidades estendida: «183 \f "Symbol" \s 12» inclui os aspectos estáticos das classes, concretizados nos seus atributos e nos seus métodos, e os aspectos dinâmicos dos objectos dessas classes, particularmente os que se relacionam com a comunicação entre eles; «183 \f "Symbol" \s 12» evidencia os elementos de interacção entre os objectos das classes representadas: especifica-se o envio e a recepção de mensagens explícitas; e especificam-se as situações de diálogo, que geralmente envolvem mensagens implícitas. 4. Conclusões e perspectivas Com o modelo das três entidades, um programa educativo deixa de ser considerado como uma entidade isolada, passando a ser uma de três entidades que devem interagir e colaborar no processo de aprendizagem dos alunos. Desta forma é necessário especificar não apenas o programa educativo, mas também as outras entidades, o aluno e o educador, que existem no contexto da sua utilização. Cada uma das três entidades é uma classe de objectos e a comunicação entre eles realiza-se através de trocas de mensagens, implícitas e explícitas, o que permite o estabelecimento de um modelo de comunicação que torne possível a existência de formas de interacção mais simétricas, em termos de controlo, entre os utilizadores e o programa educativo. O modelo das três entidades constitui apenas um enquadramento conceptual, pelo que foi orientado para a aplicação prática através de uma nova entidade, a tabela de responsabilidades estendida, em que se caracterizam as classes e as trocas de mensagens entre os objectos dessas classes. Os testes realizados com o Dice Calculation permitiram verificar que a tabela de responsabilidades estendida suporta a modelização de uma interacção mais simétrica entre o programa educativo e as outras duas entidades. Torna-se necessário realizar outros testes baseados em concepções em que essa simetria seja mais evidente, e não baseados num modelo de comunicação do tipo acção do aluno reacção do programa. Para isso é necessário explorar técnicas de

9 concepção em que possam ser expressos níveis mais elevados de simetria. Esses testes permitiram concluir também que o modelo das três entidades e a tabela de responsabilidades estendida conduzem a uma abordagem de desenvolvimento baseada em métodos orientados a objectos. Em particular, verificou-se que os cenários identificados e caracterizados na tabela de responsabilidades estendida constituem pistas válidas para a identificação das classes e dos objectos durante as actividades de análise orientada a objectos. Desta forma, o modelo das três entidades e a tabela de responsabilidades estendida facilitam a transição da fase de concepção para a fase de desenvolvimento. Para o desenvolvimento do Dice Calculation utilizámos, como metodologia de desenvolvimento, a prototipificação continuadamente evolutiva [8] e socorremo-nos de métodos orientados a objectos [6]. Reconhecemos, no entanto, que apesar de os testes realizados sugerirem as conclusões que acabamos de apresentar, é necessário maior experimentação com vista a desenvolver o modelo proposto, por um lado, e a reforçar estas conclusões, por outro. Agradecimentos Os autores agradecem ao Instituto Superior de Contabilidade e Administração de Aveiro e ao Centro de Informática e Sistemas da Universidade de Coimbra pelas facilidades concedidas na elaboração deste estudo. Referências [1] Alessi, S., e Trollip, S. Computer-Based Instruction: Methods and Development. Prentice-Hall, Inc., Englewood Cliffs, New Jersey, U.S.A., [2] Crossley, K., e Green, L. Le Design des Didacticiels: Guide Pratique pour la Conception de Scénarios Pédagogiques Interactifs. ACL-Editions, Paris, France, [3] Minken, I., Stenseth, B., e Vavik, L. Educational Software. ULTIMA-Gruppen A/S, Halden, Norway, [4] Snyder, A. The Essence of Objects: Concepts and Terms. IEEE Software 10, 1 (Janeiro, 1993), 31. [5] Batista, J., e Figueiredo, A. Object-Orientation: In Search of the Paradigm. Relatório Interno DEE-FCTUC , ISSN: , Universidade de Coimbra, Coimbra, Portugal, [6] Booch, G. Object-Oriented Analysis and Design: With Applications (second edition). The Benjamin/Cummings Publishing Company, Inc., Redwood City, California, U.S.A., [7] Laurel, B. Computers as Theatre. Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, U.S.A., [8] Batista, J., e Figueiredo, A. A Prototipificação Estruturada Aplicada ao Desenvolvimento de Programas Educativos. Dissertação de Mestrado, Faculdade de Ciências e Tecnologia, Universidade de Coimbra, Coimbra, Portugal, 1992.

DIAGRAMAS DE SEQUÊNCIA

DIAGRAMAS DE SEQUÊNCIA DIAGRAMAS DE SEQUÊNCIA Extraem-se dos UCs Martins 2008 112 DIAGRAMAS DE SEQUÊNCIA 1: withdrawmoney(amount) 2: balance = getbalance() Martins 2008 113 DIAGRAMAS DE SEQUÊNCIA simples síncrona assíncrona

Leia mais

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

Notas de Aula 03: Introdução a Orientação a Objetos e a UML Notas de Aula 03: Introdução a Orientação a Objetos e a UML Objetivos da aula: Introduzir os conceitos da Orientação à Objetos (O.O) Introduzir os conceitos da UML Relacionar os processos às ferramentas

Leia mais

Diagrama de Sequência Notação Objetos. Diagrama de Sequência Notação Mensagens. Diagrama de Sequência Notação Mensagens. Tipos de Mensagens

Diagrama de Sequência Notação Objetos. Diagrama de Sequência Notação Mensagens. Diagrama de Sequência Notação Mensagens. Tipos de Mensagens Diagrama de Sequência Diagrama de Sequência Os diagramas de sequências enfatizam a perspectiva temporal Há dois tipos de utilização desse diagrama, dependendo da fase em que estamos Documentação dos casos

Leia mais

Introdução. à UML. Histórico (cont.) Histórico Definição Benefícios Notação Diagrama de Classes Diagramas de Interação Conclusões Revisão

Introdução. à UML. Histórico (cont.) Histórico Definição Benefícios Notação Diagrama de Classes Diagramas de Interação Conclusões Revisão Sumário Introdução à UML BSI Bacharelado em Sistemas de Informação LOO Linguagens Orientadas a Objetos Humberto Mossri de Almeida hmossri_cursos@yahoo.com.br Marcelo Nassau Malta nassau_cursos@yahoo.com.br

Leia mais

Diagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência

Diagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência Diagramas Os diagramas utilizados pela UML são compostos de nove tipos: diagrama de use case, de classes, de objecto, de estado, de sequência, de colaboração, de actividade, de componente e o de instalação/execução.

Leia mais

Diagramas de Use Case

Diagramas de Use Case 86/170 Diagramas de Use Case Sumário Definição de requisitos. Diagramas de Use Case I conceitos base Diagramas de Use Case II conceitos avançados Resumo Exercícios Definição de Requisitos 87/170 Definição

Leia mais

Desenvolvimento de um modelo de ensino da Física

Desenvolvimento de um modelo de ensino da Física Desenvolvimento de um modelo de ensino da Física Modelação ou desenvolvimento de um modelo Processo cognitivo de aplicação dos princípios de uma teoria para produzir um modelo de um objecto físico ou de

Leia mais

Normalização de dados

Normalização de dados 1 Normalização de dados Vantagens da normalização A normalização permite: Agrupar os atributos de uma entidade de forma a reduzir o número de dependências funcionais existentes entre os dados numa base

Leia mais

Informática. Banco de Dados Relacional. Professor Julio Alves.

Informática. Banco de Dados Relacional. Professor Julio Alves. Informática Banco de Dados Relacional Professor Julio Alves www.acasadoconcurseiro.com.br Informática 1. BANCOS DE DADOS RELACIONAL Um BD relacional possui apenas um tipo de construção, a tabela. Uma

Leia mais

A crise do software As duas abordagens actuais para o desenvolvimento de software: abordagem clássica abordagem orientada para objectos

A crise do software As duas abordagens actuais para o desenvolvimento de software: abordagem clássica abordagem orientada para objectos 1. CONCEITOS BÁSICOS A crise do software As duas abordagens actuais para o desenvolvimento de software: abordagem clássica abordagem orientada para objectos A. Dias de Figueiredo, 1997/78 Engenharia de

Leia mais

UML Diagramas de Interação

UML Diagramas de Interação CBSI Curso de Bacharelado em Sistemas de Informação UML Diagramas de Interação Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Análise e Projeto de Sistemas Faculdade de Computação

Leia mais

CONSTRUÇÕES COM A RÉGUA E O COMPASSO, CONTRIBUIÇÕES E LIMITES DA GEOMETRIA DINÂMICA

CONSTRUÇÕES COM A RÉGUA E O COMPASSO, CONTRIBUIÇÕES E LIMITES DA GEOMETRIA DINÂMICA CONSTRUÇÕES COM A RÉGUA E O COMPASSO, CONTRIBUIÇÕES E LIMITES DA GEOMETRIA DINÂMICA Franck Bellemain Labma-IME-UFRJ, Rio de Janeiro f.bellemain@br.inter.net Mini-curso em laboratório de computadores. Geometrias

Leia mais

Introdução aos SGBD s

Introdução aos SGBD s Introdução aos SGBD s O que é uma Base de Dados? Colecção de dados ou itens de informação estruturados de determinada forma. Forma mais comum de guardar um grande volume de dados. Exemplos: Agenda de Contactos

Leia mais

ENGENHARIA DE SOFTWARE

ENGENHARIA DE SOFTWARE ENGENHARIA DE SOFTWARE Qualidade de Software Qualidade do produto e do processo Padrões de software Revisões Medições e métricas de software Kele Teixeira Belloze kelebelloze@gmail.com CONCEITO DE QUALIDADE

Leia mais

Anexo 1 Alguns exercícios da actividade diagnóstico

Anexo 1 Alguns exercícios da actividade diagnóstico Anexo 1 Alguns exercícios da actividade diagnóstico Relembre a lista de palavras incluídas na actividade diagnóstico: Geosfera Sistema Terra Biosfera Água Oxigénio molecular Hidrosfera Atmosfera Homem

Leia mais

Diagramas de Use Case Resumo

Diagramas de Use Case Resumo 0 Diagramas de Use Case Resumo Os diagramas de Use Case permitem definir os requisitos funcionais de um sistema: que serviços deve fornecer; a quem os deve fornecer. Notação diagramática facilita o diálogo

Leia mais

Diagrama de Máquina de Estados

Diagrama de Máquina de Estados Análise e Projeto de Sistemas OO Diagrama de Máquina de Estados Demonstra o comportamento de um elemento através de um conjunto de transições de estado. Um Estado representa a situação em que um objeto

Leia mais

MATA60 BANCO DE DADOS Aula 3- Modelo de Entidades e Relacionamentos. Prof. Daniela Barreiro Claro

MATA60 BANCO DE DADOS Aula 3- Modelo de Entidades e Relacionamentos. Prof. Daniela Barreiro Claro MATA60 BANCO DE DADOS Aula 3- Modelo de Entidades e Relacionamentos Prof. Daniela Barreiro Claro Agenda Modelo de Dados MER 2 de X; X=37 Modelo de Dados O Modelo de Dados é a principal ferramenta que fornece

Leia mais

UML Aula I Diagramas de Caso de Uso. Ricardo Argenton Ramos

UML Aula I Diagramas de Caso de Uso. Ricardo Argenton Ramos UML Aula I Diagramas de Caso de Uso Ricardo Argenton Ramos Engenharia de Software II 2016.1 25/04/2016 Um Exercício Como você pode representar? Uma casa de 2 andares, 4 quartos, 2 banheiros, 1 sala, 1

Leia mais

Diagramas de Interacção

Diagramas de Interacção 24 Diagramas de Interacção Sumário: Tipos de Diagramas de Interacção Interacções Diagramas de Comunicação conceitos base Diagramas de Sequência conceitos base Diagramas de Comunicação conceitos avançados

Leia mais

Unidade 1 Introdução à Análise de Sistemas. Objectivos

Unidade 1 Introdução à Análise de Sistemas. Objectivos Unidade 1 Introdução à Análise de Sistemas Objectivos 1 2 Objectivos Definir a análise de sistemas Reconhecer as funções do analista de sistemas Definir conceitos de sistema Reconhecer a finalidade do

Leia mais

Interacção Pessoa-Computador

Interacção Pessoa-Computador Trabalho Individual 1: Análise de Má Usabilidade no Mircosoft Paint Proposta de Melhorias. Conceitos: (1): Interacção Pessoa-Computador Interacção Pessoa-Computador: - É o estudo da interacção entre o

Leia mais

Modelagem de dados usando o modelo Entidade- Relacionamento (ER)

Modelagem de dados usando o modelo Entidade- Relacionamento (ER) Modelagem de dados usando o modelo Entidade- Relacionamento (ER) slide 1 Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Tópicos Usando modelo de dados conceituais de alto nível

Leia mais

Análise Estruturada. Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.

Análise Estruturada. Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D. Análise Estruturada Análise estruturada Proposta a partir de 1975 por vários autores (Constantine, Tom DeMarco, Yourdon, Gane & Sarson) Caiu em desuso com os modelos orientados a objetos Entretanto...

Leia mais

Modelo Lógico de Dados (MLD) Origens do modelo relacional

Modelo Lógico de Dados (MLD) Origens do modelo relacional Modelo Lógico de Dados (MLD) O MLD é derivado a partir do MCD pela aplicação de um conjunto de regras bem definidas; A derivação do MLD depende fortemente dos conceitos e tecnologias subjacentes do MLD;

Leia mais

Tópicos da Aula. Alguns Diagramas UML. Diagramas Principais. Diagramas de Interação: Sequência e Colaboração. Tipos de Diagramas de Interação

Tópicos da Aula. Alguns Diagramas UML. Diagramas Principais. Diagramas de Interação: Sequência e Colaboração. Tipos de Diagramas de Interação Engenharia de Software Aula 10 Tópicos da Aula Diagramas de Interação: Sequência e Colaboração Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 09 Abril 2012 Alguns Diagramas UML

Leia mais

Dinâmica dos Objetos

Dinâmica dos Objetos Dinâmica dos Objetos Dinâmica dos objetos Necessário desenvolver estudo sobre comportamento interno das classes Permitir a especificação da dinâmica i.e. a forma como os objetos de cada classe se comportam

Leia mais

António Rocha Nuno Melo e Castro

António Rocha Nuno Melo e Castro António Rocha Nuno Melo e Castro O modelo E-R (entidade-relacionamento) baseia-se na percepção de um universo constituído por um grupo básico de objectos chamados Entidades e por Relacionamentos entre

Leia mais

ISO 9000:2005 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO As Normas da família ISO 9000

ISO 9000:2005 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO As Normas da família ISO 9000 ISO 9000:2005 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário João Noronha ESAC/IPC 1 As Normas da família ISO 9000 ISO 9000 descreve os fundamentos de sistemas de gestão da qualidade e especifica

Leia mais

MDS II Aula 04. Concepção Requisitos Diagrama de Casos de Uso (Use Cases)

MDS II Aula 04. Concepção Requisitos Diagrama de Casos de Uso (Use Cases) MDS II Aula 04 Concepção Requisitos Diagrama de Casos de Uso (Use Cases) 55 DIAGRAMA DE CASOS DE USO BENEFÍCIOS DOS CASOS DE USO ILUSTRAR POR QUE O SISTEMA É NECESSÁRIO OS REQUISITOS DO SISTEMA SÃO COLOCADOS

Leia mais

Engenharia de Software 2012/3 Aula 5 Modelagem de Sistemas

Engenharia de Software 2012/3 Aula 5 Modelagem de Sistemas Engenharia de Software Engenharia de Software 2012/3 Aula 5 Modelagem de Sistemas Thiago P. da Silva thiagosilva@ufmt.br Agenda Modelagem de Sistemas Modelos de contexto Diagramas de Atividades Modelos

Leia mais

!" # Modelos de dados. 1ª geração. 2ª geração. 3ª geração. Modelo Hierárquico Modelo Rede. Modelo Relacional

! # Modelos de dados. 1ª geração. 2ª geração. 3ª geração. Modelo Hierárquico Modelo Rede. Modelo Relacional Nuno Melo e Castro !" # Modelos de dados 1ª geração Modelo Hierárquico Modelo Rede 2ª geração Modelo Relacional 3ª geração Extensões ao modelo relacional Modelo lógico-dedutivo Modelo orientado a objectos

Leia mais

A Informática Na Educação: Como, Para Que e Por Que

A Informática Na Educação: Como, Para Que e Por Que RBEBBM -01/2001 A Informática Na Educação: Como, Para Que e Por Que Autores:José A. Valente Afiliação:Departamento de Multimeios e Nied - Universidade Estadual de Campinas - Unicamp, Campinas - SP javalente@unicamp.br

Leia mais

Função Fundamental do SO

Função Fundamental do SO Função Fundamental do SO Gestão do Hardware Uma das funções fundamentais do sistema operativo é gerir os recursos do hardware de um modo o mais transparente possível ao utilizador Recursos principais a

Leia mais

Factores-chave para a Gestão da Inovação

Factores-chave para a Gestão da Inovação Factores-chave para a Gestão da Inovação Uma proposta João M. Alves da Cunha CCDR Alg, Maio de 009 Introdução O Innovation Scoring enquanto instrumento de apoio à gestão da Inovação SG IDI Sistema de Gestão

Leia mais

Banco de Portugal. Carta-Circular nº 1/2006/DSB, de

Banco de Portugal. Carta-Circular nº 1/2006/DSB, de Banco de Portugal Carta-Circular nº 1/2006/DSB, de 3-01-2006 ASSUNTO: Início do Processo Informal de Candidatura para a Utilização dos Sistemas de Notações Internas (risco de crédito) e das Abordagens

Leia mais

Engenharia de Software I: Introdução. Graduação em Informática 2009 Profa. Itana Gimenes

Engenharia de Software I: Introdução. Graduação em Informática 2009 Profa. Itana Gimenes Engenharia de Software I: Introdução Graduação em Informática 2009 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. Engenharia de requisitos 3. Modelagem de sistemas 4. Conceitos

Leia mais

Análise da Informação Económica e Empresarial

Análise da Informação Económica e Empresarial Análise da Informação Económica e Empresarial Aula 4: Noções fundamentais sobre a realização de trabalho empírico em Economia e Gestão tratamento de informação e elaboração de relatórios Análise da Informação

Leia mais

3. REPRESENTAÇÃO DE SISTEMAS

3. REPRESENTAÇÃO DE SISTEMAS 3. REPRESENTAÇÃO DE SISTEMAS A abordagem à teoria dos sistemas, seguida até agora, partiu de alguns exemplos de sistemas físicos, determinou descrições das suas dinâmicas em termos de equações diferenciais

Leia mais

Simulado para CFPS. Questões de Propósito, Tipo e Fronteira. 1. Um dos objetivos da Análise de Pontos de Função é:

Simulado para CFPS. Questões de Propósito, Tipo e Fronteira. 1. Um dos objetivos da Análise de Pontos de Função é: Questões de Propósito, Tipo e Fronteira 1. Um dos objetivos da Análise de Pontos de Função é: Simulado para CFPS a) Ajudar no processo de depuração de um software. b) Estimar o tamanho de uma equipe de

Leia mais

Aula 3 - Modelo Entidade-Relacionamento

Aula 3 - Modelo Entidade-Relacionamento Aula 3 - Modelo Entidade-Relacionamento 1. Conceitos básicos O modelo Entidade-Relacionamento (E-R) tem por base a percepção de que o mundo real é formado por um conjunto de objetos chamados de entidades

Leia mais

2. Modelação da Interface com o Utilizador

2. Modelação da Interface com o Utilizador SISTEMAS DE INFORMAÇÃO Modelação do Conhecimento e Bases de Dados 2. Modelação da Interface com o Utilizador 1999 João Falcão e Cunha 2.1 Introdução ao Processo de Modelação Problemas e Modelos; Objectivos

Leia mais

Modelo Relacional Normalização Diagramas E-R e Tabelas Originadas

Modelo Relacional Normalização Diagramas E-R e Tabelas Originadas Informática II Modelo Relacional Normalização Diagramas E-R e Tabelas Originadas (TÓPICOS ABORDADOS NAS AULAS DE INFORMÁTICA II) Por: Artur Sousa / Jorge Loureiro Conceitos de entidade e atributo Tipos

Leia mais

UML - Diagramas de Sequência

UML - Diagramas de Sequência UML - Diagramas de Sequência 1 Objectivo Um diagrama de sequência mostra uma interacção, isto é, uma sequência de mensagens trocadas entre vários objectos num determinado contexto (caso de utilização,

Leia mais

Requisitos de Sistemas

Requisitos de Sistemas Requisitos de Sistemas Unidade I - Engenharia de Requisitos Definição de Requisitos (Continuação) Processos de Engenharia de Requisitos (Cont.) - Análise - Registro - Validação - Gerência 1 Processo de

Leia mais

A construção do Sistema de Numeração Decimal SND e Testagem com criança de 6 a 9 anos

A construção do Sistema de Numeração Decimal SND e Testagem com criança de 6 a 9 anos A construção do Sistema de Numeração Decimal SND e Testagem com criança de 6 a 9 anos *as idades são referências, podem variar conforme o contexto Curso Construção de jogos, materiais e atividades de Matemática

Leia mais

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO SISTEMAS DE GESTÃO DE BASE DE DADOS FORMULÁRIOS

TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO SISTEMAS DE GESTÃO DE BASE DE DADOS FORMULÁRIOS TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO SISTEMAS DE GESTÃO DE BASE DE DADOS FORMULÁRIOS Os constituem uma outra forma de visualizar os dados armazenados nas tabela ou disponibilizados numa consulta. Também

Leia mais

MODELAGEM DE DADOS MÓDULO III - UNIDADE V- MAPEAMENTO OBJETO RELACIONAL

MODELAGEM DE DADOS MÓDULO III - UNIDADE V- MAPEAMENTO OBJETO RELACIONAL MODELAGEM DE DADOS MÓDULO III - UNIDADE V- MAPEAMENTO OBJETO RELACIONAL 0 UNIDADE V: MAPEAMENTO OBJETO RELACIONAL Paradigma da Orientação a Objetos: Este paradigma parte do princípio que existem diversos

Leia mais

Inteligência Artificial Projecto 1

Inteligência Artificial Projecto 1 Bantumi ESPECIFICAÇÕES O projecto destina-se a resolver um conjunto de problemas do jogo Bantumi utilizando métodos de procura em espaço de estados. Bantumi é um jogo derivado do jogo Mancala de origem

Leia mais

Processos de software

Processos de software Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos de

Leia mais

BPFs / HACCP 1 BOAS PRÁTICAS DE FABRICO HACCP (HAZARD ANALYSIS AND CRITICAL CONTROL POINTS) João Gusmão Lisboa, Dezembro 2003

BPFs / HACCP 1 BOAS PRÁTICAS DE FABRICO HACCP (HAZARD ANALYSIS AND CRITICAL CONTROL POINTS) João Gusmão Lisboa, Dezembro 2003 BPFs / HACCP 1 BOAS PRÁTICAS DE FABRICO HACCP (HAZARD ANALYSIS AND CRITICAL CONTROL POINTS) João Gusmão Lisboa, Dezembro 2003 BPFs / HACCP 2 SEGURANÇA A SEGURANÇA DO PRODUTO ALIMENTAR CONSTITUI UM REQUISITO

Leia mais

UML (Linguagem unificada de modelagem)

UML (Linguagem unificada de modelagem) UML (Linguagem unificada de modelagem) Modelo de Casos de Uso -> descritos através de Diagramas de Caso de uso Determinação dos usos que o sistema terá (requisitos funcionais) captura os usos ou aplicações

Leia mais

MODELO DE BANCO DE DADOS RELACIONAL

MODELO DE BANCO DE DADOS RELACIONAL UNINGÁ UNIDADE DE ENSINO SUPERIOR INGÁ FACULDADE INGÁ CIÊNCIA DA COMPUTAÇÃO BANCO DE DADOS I MODELO DE BANCO DE DADOS RELACIONAL Profº Erinaldo Sanches Nascimento Objetivos Descrever os princípios básicos

Leia mais

Como Modelar com UML 2

Como Modelar com UML 2 Ricardo Pereira e Silva Como Modelar com UML 2 Visual Books Sumário Prefácio... 13 1 Introdução à Modelagem Orientada a Objetos... 17 1.1 Análise e Projeto Orientados a Objetos... 18 1.2 Requisitos para

Leia mais

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software ENGENHARIA DE SOFTWARE Aula 03 Processos de Software AGENDA Modelos de processo de software Atividades do processo Lidando com mudanças Rational Unified Process (RUP) 14/03/2017 IFPR QUEDAS DO IGUAÇU -

Leia mais

Desenho de Software. Sumário

Desenho de Software. Sumário (QJHQKDULDGD3URJUDPDomR Desenho de Software Carla Ferreira Carla.Ferreira@dei.ist.utl.pt Sumário Objectivos Problemas Qualidades Técnicas Avaliação e Validação Casos Notáveis Exemplo Conclusões Desenho

Leia mais

MODELAGEM DE DADOS UNIDADE 3 Modelo Entidade-Relacionamento. Luiz Leão

MODELAGEM DE DADOS UNIDADE 3 Modelo Entidade-Relacionamento. Luiz Leão Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático 3.1 Modelo Entidade-Relacionamento 3.1.1 Modelo de Banco de Dados 3.1.2 Modelo Conceitual 3.1.3 Modelo lógico 3.2 As Principais

Leia mais

DE QUE MODO ACTUAM OS

DE QUE MODO ACTUAM OS PREDADORES ONLINE Quando as crianças utilizam ferramentas de comunicação na Internet, como salas de chat, correio electrónico e mensagens instantâneas, estão vulneráveis a interagir com predadores online.

Leia mais

Curso teórico: Orientação a Objetos. Matemática computacional Marcos Aurelio Wozhiak Jr webzhiak.com.br

Curso teórico: Orientação a Objetos. Matemática computacional Marcos Aurelio Wozhiak Jr webzhiak.com.br Curso teórico: Orientação a Objetos Matemática computacional Marcos Aurelio Wozhiak Jr webzhiak.com.br Objetivos Conhecer os conceitos fundamentais de orientação a objetos; Aprender a criar e utilizar

Leia mais

4 Uma Linguagem Baseada em Máquinas de Estado 4.1. A Linguagem

4 Uma Linguagem Baseada em Máquinas de Estado 4.1. A Linguagem 4 Uma Linguagem Baseada em Máquinas de Estado 4.1. A Linguagem Acredita-se nesse trabalho que características reativas e fortemente baseadas em modelos tornam necessária a criação de uma linguagem específica

Leia mais

UNIP Ciência da Computação AES Análise Essencial de Sistemas MER (Modelo Entidade Relacionamento)

UNIP Ciência da Computação AES Análise Essencial de Sistemas MER (Modelo Entidade Relacionamento) MER (Modelo Entidade Relacionamento) O Modelo Entidade Relacionamento é uma ferramenta para modelagem de dados, utilizada durante a modelagem do projeto conceitual de banco de dados. A utilização do MER

Leia mais

PARADIGMAS SOCIOLÓGICOS DECORREM DA FORMA DE VER A RELAÇÃO ENTRE O INDIVÍDUO E A SOCIEDADE.

PARADIGMAS SOCIOLÓGICOS DECORREM DA FORMA DE VER A RELAÇÃO ENTRE O INDIVÍDUO E A SOCIEDADE. PARADIGMAS SOCIOLÓGICOS DECORREM DA FORMA DE VER A RELAÇÃO ENTRE O INDIVÍDUO E A SOCIEDADE. 1. Teorias que consideram que a sociedade é uma instância que se impõe aos indivíduos sendo estes produto dessa

Leia mais

Informação Prova de equivalência à frequência

Informação Prova de equivalência à frequência Informação Prova de equivalência à frequência 3.º Ciclo do Ensino Básico 1ª e 2ª fases Ano Letivo 2013/2014 Disciplina: História Duração: 90 minutos Decreto-Lei n.º 139/2012, de 5 de julho 1.INTRODUÇÃO

Leia mais

Diagramas Entidade-Relação

Diagramas Entidade-Relação Diagramas Entidade-Relação (DER) Diagramas Patas de Corvos (com algumas adaptações próprias). Diagramas Entidade-Relação id Rectângulos representam entidades; Losangos representam associações; Linhas unem

Leia mais

Marcelo Henrique dos Santos

Marcelo Henrique dos Santos Marcelo Henrique dos Santos Mestrado em Educação (em andamento) MBA em Marketing e Vendas (em andamento) Especialista em games Bacharel em Sistema de Informação Email: marcelosantos@outlook.com SISTEMAS

Leia mais

Diagrama de Comunicação

Diagrama de Comunicação Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide Medeiros, E. Desenvolvendo Software

Leia mais

MODELO ORGANIZATIVO DO ENSINO DA CIÊNCIA

MODELO ORGANIZATIVO DO ENSINO DA CIÊNCIA Um padrão para a unificação de conceitos e procedimentos pode ser definido verticalmente e transversalmente para todos os anos de escolaridade A compreensão e as aptidões associadas à maioria dos esquemas

Leia mais

Aula 01 Conceito de Banco de Dados e SGBD

Aula 01 Conceito de Banco de Dados e SGBD Aula 01 Conceito de Banco de Dados e SGBD Dado: conjunto de símbolos arranjados a fim de representar a informação fora da mente humana. Elemento de Dado: subconjunto de símbolos que compõem um dado com

Leia mais

Introdução INTRODUÇÃO AO SWEBOK. Origens do corpo de conhecimentos da Engenharia de Software: Introdução a Computação e Engenharia de Software

Introdução INTRODUÇÃO AO SWEBOK. Origens do corpo de conhecimentos da Engenharia de Software: Introdução a Computação e Engenharia de Software INTRODUÇÃO AO SWEBOK Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Origens do corpo de conhecimentos da Engenharia de Software: Engenharia da Computação Ciência da

Leia mais

CALCULADORA SIMPLES COM ULA

CALCULADORA SIMPLES COM ULA CALCULADORA SIMPLES COM ULA Versão 2013 RESUMO 1 Esta experiência tem por objetivo a utilização de circuitos integrados de operações lógicas e aritméticas para o desenvolvimento de circuitos que executam

Leia mais

AULA ANTERIOR: MODELOS FUNDAMENTAIS

AULA ANTERIOR: MODELOS FUNDAMENTAIS AULA ANTERIOR: MODELOS FUNDAMENTAIS Modelos fundamentais de um sistema distribuído Permitem estabelecer quais as premissas existentes a respeito de aspetos chave. Permitem avaliar de forma objetiva as

Leia mais

O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado.

O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado. Modelagem de casos de uso Casos de uso O conceito de casos de uso foi criado em 1986 por Ivar Jacobson, metodologista e um dos pais do Processo Unificado. O que é Segundo Ivar Jacobson, um caso de uso

Leia mais

AULA 02. OBJETIVO: Características da Linguagem Orientada a Objetos.

AULA 02. OBJETIVO: Características da Linguagem Orientada a Objetos. AULA 02 OBJETIVO: Características da Linguagem Orientada a Objetos. HABILIDADES TRABALHADAS: Comparação das características das linguagens orientadas a objetos frente às linguagens estruturadas. Conhecimentos

Leia mais

Reuso de Software Aula Maio 2012

Reuso de Software Aula Maio 2012 Reuso de Software Aula 19 Tópicos da Aula Engenharia de Software baseada em Componentes (CBSE) Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com Componentes Modelos de Componentes

Leia mais

Especificação, Modelação e Projecto de Sistemas Embutidos

Especificação, Modelação e Projecto de Sistemas Embutidos Especificação, Modelação e Projecto de Sistemas Embutidos Linguagens de especificação: SDL Paulo Pedreiras, Luís Almeida {pbrp,lda}@ua.pt Departamento de Electrónica, Telecomunicações e Informática Universidade

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 5 Técnicas de Especificação SUMÁRIO INTRODUÇÃO... 3 TÉCNICAS PARA PROJETO DE CASOS

Leia mais

Tecnologias da Informação e Comunicação: Sistema Operativo em Ambiente Gráfico

Tecnologias da Informação e Comunicação: Sistema Operativo em Ambiente Gráfico Tecnologias da Informação e Comunicação UNIDADE 1 Tecnologias da Informação e Comunicação: Sistema Operativo em Ambiente Gráfico 1º Período SUMÁRIO Sistema Operativo: definição e tipos. Elementos básicos

Leia mais

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F. Diagramas UML Classe, Seqüência e Atividades Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 15 de maio

Leia mais

Registo de Acompanhamento de Projecto

Registo de Acompanhamento de Projecto Registo de Acompanhamento de Projecto O SharpFlow, para além de gerir individualmente as tarefas relacionadas com um projecto, permite também controlar o fluxo e evolução do próprio projecto ao longo do

Leia mais

Excel - Funções Estatísticas

Excel - Funções Estatísticas Excel - Funções Estatísticas DEPARTAMENTO DE CIÊNCIAS E TECNOLOGIAS DA INFORMAÇÃO 1 Descrição geral: Utilizar funções e fórmulas estatísticas Obtenha informações sobre como utilizar funções e fórmulas

Leia mais

Sistemas de numeração e conversão de bases Decimal e binário

Sistemas de numeração e conversão de bases Decimal e binário Sistemas de numeração e conversão de bases Decimal e binário Cálculo de conversão de bases para responder às questões pertinentes à execução das especificações nas configurações de sistemas, comunicação

Leia mais

Programação Orientada a Objectos - P. Prata, P. Fazendeiro

Programação Orientada a Objectos - P. Prata, P. Fazendeiro 3 Classes e instanciação de objectos (em Java) Suponhamos que queremos criar uma classe que especifique a estrutura e o comportamento de objectos do tipo Contador. As instâncias da classe Contador devem

Leia mais

O uso dos jogos como estratégia de aprendizagem para alunos do 1º ciclo do ensino básico. O caso do CD-ROM Escola Digital

O uso dos jogos como estratégia de aprendizagem para alunos do 1º ciclo do ensino básico. O caso do CD-ROM Escola Digital O uso dos jogos como estratégia de aprendizagem para alunos do 1º ciclo do ensino básico. O caso do CD-ROM Escola Digital Steven Lopes Abrantes 5 de Junho de 2007 DEGEI Universidade de Aveiro Organização

Leia mais

Padrão para Especificação de Requisitos de Produto de Multimídia

Padrão para Especificação de Requisitos de Produto de Multimídia Padrão para Especificação de Requisitos de Produto de Multimídia 1 Introdução 1.1 Escopo do documento Sugere-se aqui uma estrutura para a Especificação de Requisitos de Produto de Multimídia (ERPM). Esta

Leia mais

Q d( ) P. a( ) c( ) e( ) c( ) S. c( ) d( )

Q d( ) P. a( ) c( ) e( ) c( ) S. c( ) d( ) ELEMENTOS BÁSICOS DA LINGUAGEM JAVA Patricia Della Méa Plentz INE-CTC-UFSC E-Mail: plentz@inf.ufsc.br URL: http://moodle.ufsc.br INE5605-Turma 0238B Sumário 2.1 Classes e Objetos na POO 2.2 2 Revisão da

Leia mais

Definições (II) Page 3

Definições (II) Page 3 Casos de Uso Prof. Esp. MBA. Heuber Lima Definições Um caso de uso especifica o comportamento de um sistema ou um subsistema e corresponde a uma descrição de uma série de seqüências de ação, e suas respectivas

Leia mais

Classes o Objetos. Classes, objetos, métodos e variáveis de instância

Classes o Objetos. Classes, objetos, métodos e variáveis de instância Classes o Objetos Um recurso comum de cada aplicativo feito até agora é que todas as instruções que realizavam tarefas localizavam-se no método main. Se você tornar parte de uma equipe de desenvolvimento

Leia mais

Programa de Matemática 1.º ano

Programa de Matemática 1.º ano Programa de Matemática 1.º ano Introdução A Matemática é uma das ciências mais antigas e é igualmente das mais antigas disciplinas escolares, tendo sempre ocupado, ao longo dos tempos, um lugar de relevo

Leia mais

Colégio Valsassina. Modelo pedagógico do jardim de infância

Colégio Valsassina. Modelo pedagógico do jardim de infância Colégio Valsassina Modelo pedagógico do jardim de infância Educação emocional Aprendizagem pela experimentação Educação para a ciência Fatores múltiplos da inteligência Plano anual de expressão plástica

Leia mais

Modelo Relacional. Aula 02

Modelo Relacional. Aula 02 Aula 02 Modelo Relacional É um modelo baseado em relações, seus dados no BD são representados através de tabelas, ou seja, sua coleção ou relação recebe cada uma um nome único. Revisando: Dados: é o conteúdo

Leia mais

Consultas I Para que servem? Como funcionam Tipos de consulta Consultas Selecção Consultas parametrizadas Consultas Tabela de referência cruzada

Consultas I Para que servem? Como funcionam Tipos de consulta Consultas Selecção Consultas parametrizadas Consultas Tabela de referência cruzada Consultas I Para que servem? Servem para analisar, filtrar, agrupar e/ou alterar dados de diversas maneiras e podem servir como origem de registos para formulários e relatórios Como funcionam As consultas

Leia mais

1 Introdução. 1.1 Teoria dos Sistemas 23/4/2010

1 Introdução. 1.1 Teoria dos Sistemas 23/4/2010 1 1 Introdução 1.1 Teoria dos Sistemas 1.2 Constituição dos sistemas 1.3 Natureza dos sistemas 1.4 Parâmetros do sistema 1.5 Descrição de sistemas 1.6 Desafios enfrentados no desenvolvimento 1.7 Perfil

Leia mais

Diferenciação Funcional Taxonomias PRIMAVERA ERP 9.15

Diferenciação Funcional Taxonomias PRIMAVERA ERP 9.15 Diferenciação Funcional Taxonomias PRIMAVERA ERP 9.15 Versão 1.0 Abril de 2017 Índice Índice... 2 Introdução... 3 Módulo Contabilidade... 4 Referencial contabilístico...4 Plano alternativo...5 Máscaras

Leia mais

Abordagem ER. Capítulo 2

Abordagem ER. Capítulo 2 $ Abordagem ER Capítulo 2 # Abordagem Entidade-Relacionamento Técnica para construir modelos conceituais de bases de dados Técnica de modelagem de dados mais difundida e utilizada Criada em 1976, por Peter

Leia mais

Introdução a UML e seus diagramas

Introdução a UML e seus diagramas Introdução a UML e seus diagramas A Unified Modelling Language (UML) é uma linguagem ou notação de diagramas para especificar, visualizar e documentar modelos de software orientados por objetos. O UML

Leia mais

Diagramas de Package

Diagramas de Package 190 Diagramas de Package À medida que os sistemas software se tornam mais complexos e o número de classes aumenta: Torna-se difícil efectuar a gestão das diversas classes A identificação de uma classe

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Prof. André Luiz Ribeiro Prof. Jorge Luis Pirolla Introdução à Computação Engenharia de Software Tópicos O que é Engenharia de Software? Engenharia de Software em camadas Processo

Leia mais

IMPLEMENTAÇÃO DO PROGRAMA DE PORTUGUÊS DO ENSINO BÁSICO. Escola Básica Integrada de Rabo de Peixe

IMPLEMENTAÇÃO DO PROGRAMA DE PORTUGUÊS DO ENSINO BÁSICO. Escola Básica Integrada de Rabo de Peixe IMPLEMENTAÇÃO DO PROGRAMA DE PORTUGUÊS DO ENSINO BÁSICO Escola Básica Integrada de Rabo de Peixe Sumário Introdução 2 PONTOS DE PARTIDA: Currículo Nacional do Ensino Básico publicado em 2001. O Programa

Leia mais

FORMAÇÃO PROFISSIONAL DO PESSOAL NÃO DOCENTE

FORMAÇÃO PROFISSIONAL DO PESSOAL NÃO DOCENTE FORMAÇÃO PROFISSIONAL DO PESSOAL NÃO DOCENTE ESTABELECIMENTOS DE EDUCAÇÃO E ENSINO NÃO SUPERIOR DIRECÇÃO GERAL DOS RECURSOS HUMANOS DA EDUCAÇÃO DIVISÃO DE APOIO À FORMAÇÃO DO PESSOAL NÃO DOCENTE CARACTERIZAÇÃO

Leia mais