De Arte a Ciência: Regras para o Desenho de Software

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

Download "De Arte a Ciência: Regras para o Desenho de Software"

Transcrição

1 De Arte a Ciência: Regras para o Desenho de Software Neste artigo é apresentado um conjunto de regras de desenho um padrão de desenho universal associado ao princípio fundamental e aos requisitos axiomáticos. O padrão de desenho universal apresenta quatro tipos de elementos de design que, em conjunto, podem descrever todo um sistema de software numa única visão. Cada tipo de elemento de desenho tem a ver com um e apenas com um dos seguintes quatro aspectos da operação do sistema: estruturas de dados e operações primitivas, interfaces externas (hardware), algoritmos de sistema, fluxo de dados e sequência de acções Porque precisamos de regras de desenho Um princípio fundamental é uma lei fundamental estabelecida ou uma verdade largamente aceite que rege um campo específico da ciência ou da engenharia. Para a área da construção, por exemplo, a lei da gravidade é um princípio fundamental. Na primeira parte deste artigo propusemos que o desenvolvimento de software também tem um princípio fundamental: o software corre em hardware e interage com hardware hardware esse que tem uma velocidade finita. Apesar dos princípios fundamentais serem a base de todo o raciocínio científico, fornecem pouca ajuda prática a um engenheiro que tem pela frente um trabalho de desenho. Normalmente, são demasiado abstractos ou demasiado pesados para serem implementados directamente. Mesmo assim, os princípios fundamentais incluem requisitos axiomáticos requisitos que se aplicam a todos os sistemas que foram e serão criados. Na área da construção, por exemplo, a ideia de que o edifício deve suportar a força da gravidade constitui um requisito axiomático. Obviamente, todos os edifícios têm que satisfazer este requisito. O desenvolvimento de software também tem requisitos axiomáticos, como vimos na primeira parte deste artigo. O software tem que obter dados de uma ou mais interfaces externas (hardware). O software tem que disponibilizar dados para uma ou mais interfaces externas (hardware). O software tem que manter dados internos para serem utilizados e actualizados a cada ciclo de execução. O software tem que transformar os dados de entrada em dados de saída (utilizando possivelmente os dados internos).

2 O software tem que efectuar transformações de dados tão rapidamente quanto possível. A partir dos seus requisitos axiomáticos, todas as disciplinas tradicionais da engenharia têm derivado um conjunto de regras de desenho. Na área da construção civil, por exemplo, uma regra de desenho é a que se segue: uma parede mestra (destinada a suportar peso) tem que estar sempre posicionada por cima de uma parede mestra. O propósito desta regra de desenho consiste em ajudar os engenheiros a criar arquitecturas que satisfaçam os requisitos axiomáticos. Se um desenho arquitectural obedecer a todas as regras de desenho, então os engenheiros saberão a priori que satisfaz os requisitos axiomáticos e, consequentemente, será consistente com os princípios fundamentais da disciplina. As regras de desenho permitem que os engenheiros demonstrem facilmente a qualidade de uma arquitectura antes de iniciarem os trabalhos de construção. É necessário, portanto, encontrar as regras de desenho do desenvolvimento de software que estão associadas aos cinco requisitos axiomáticos apresentados atrás. O padrão de desenho universal As regras de desenho assumem várias formas. Podem ser muito explícitas, como uma lista de declarações imperativas do tipo o especialista em desenvolvimento de software deve, mas também podem ser mais subtis, como um conjunto de elementos de desenho predefinidos incluídos numa linguagem de desenho. Se uma linguagem de desenho incluir classes, por exemplo, então uma regra de desenho implícita será utilize classes para o desenho de software. A maior parte dos métodos de desenho de software disponibilizam, tanto um conjunto de elementos de desenho predefinidos, como regras narrativas sobre a forma como utilizar esses elementos de desenho. Comecemos pelos elementos de desenho. Convém ter em conta que as linguagens de desenho existentes, como a Unified Modeling Language (UML) não disponibilizam muita ajuda. A UML, por exemplo, é um sistema de notação ad hoc, sem princípios fundamentais subjacentes e sem requisitos axiomáticos. Os elementos de desenho foram escolhidos devido ao seu grande poder expressivo e porque a experiência e erro provaram a sua utilidade. Não estes os elementos de desenho de que estamos à procura. Em vez disso, precisamos dos elementos de desenho mais restritivos possível elementos que forcem os especialistas em desenvolvimento de software a criar arquitecturas que satisfaçam os nossos requisitos axiomáticos i. Os seguintes quatro tipos de elementos de desenho inserem-se nesta descrição. Entidade de dados As entidades de dados representam os dados entrados e saídos do sistema de software, assim como os dados internos. Servidor I/O Os servidores de I/O encapsulam as interfaces externas (hardware) com as quais interage o software. Os servidores de I/O também podem ser servidores puros de entrada ou de saída. Servidor de transformação Os servidores de transformação efectuam a transformação de dados de entrada em dados de saída, ao mesmo tempo que actualizam possivelmente os dados internos. Gestor de fluxo de dados Os gestures de fluxos de dados obtêm dados de entrada dos servidores de I/O, invocam os servidores de transformação (que transformam os dados de entrada em dados de saída) e disponibilizam dados de saída aos servidores de I/O. Os gestores de fluxos de dados também detêm os dados internos.

3 Os requisitos axiomáticos 1 a 4 implicam claramente a presença de entidades de dados, servidores de I/O e servidores de transformação. Mas para que queremos os gestores de fluxos de dados? A resposta é que os gestores de fluxos de dados tornam o fluxo de execução explícito. Isto, por sua vez, permite que um especialista em desenvolvimento de software mostre que uma arquitectura satisfaz o requisito axiomático 5: o software efectua a transformação de dados tão rápido quanto possível. Sem gestores de fluxos de dados por exemplo, com os outros elementos de desenho a enviarem mensagens uns para os outros o fluxo de execução tornarse-ia rapidamente impossível de acompanhar e, consequentemente, o tempo de execução seria imprevisível. Figura 1. Um desenho de arquitectura simples. A Figura 1 é um exemplo de um desenho arquitectural muito simples, utilizando os elementos de desenho apresentados atrás. Um desenho mais complexo poderá ter múltiplos gestores de fluxos de dados, múltiplos servidores de I/O e múltiplos servidores de transformação. Cada gestor de fluxo de dados poderá obter entradas a partir de vários servidores de I/O em diferentes pontos e disponibilizar saídas para diferentes servidores de I/O. Além disso, poderão existir bases de dados internas ou serviços abstractos representados por servidores I/O. Cada tipo de elemento de desenho tem uma natureza distinta e uma responsabilidade distinta dentro de um sistema de software. As propriedades e as responsabilidades sobrepõem-se muito pouco e os elementos de desenho do padrão de desenho universal complementam-se bem uns aos outros. Apresentamos de seguida uma lista de regras narrativas que descrevem mais detalhadamente como é que os elementos de desenho do padrão universal de desenho devem ser utilizados e implementados. Entidade de dados Cada entidade de dados é um objecto passivo de uma classe sem estado. As entidades de dados podem ser construídas a partir de entidades de dados mais básicas, através de agregação e herança. As operações primitivas de uma entidade

4 de dados são implementadas como métodos da sua classe. As operações primitivas de uma entidade de dados nunca invocam operações de um servidor de transformação ou um servidor de I/O. Servidor I/O Externamente, os servidores de I/O são elementos de sistema passivos. Não despacham dados de entrada, nem actuam noutros elementos de sistema. Os servidores de I/O têm uma interface externa bastante uniforme, baseada apenas nas operações Get, Put e Wait (e combinações). Internamente, a maior parte dos servidores de I/O têm uma sequência independente de controlo e mantêm o estado global para responder a eventos de hardware e a pedidos de clientes (gestor de fluxo de dados). Os servidores de I/O têm a capacidade de manter em buffer dados de entrada e dados de saída. Quando um gestor de fluxos de dados invoca uma operação de servidor de I/O, o servidor de I/O recupera tipicamente os dados de entrada do um buffer e guarda os dados de saída num buffer. No entanto, os algoritmos através dos quais um servidor de I/O gere os seus buffers de dados têm que ser simples. Um servidor de I/O nunca invoca directamente operações de servidor de transformação. Servidor de transformação Os servidores de transformação são elementos de sistema passivos e sem estado. Cada servidor de transformação implementa uma operação de transformação de dados, que é regida por um algoritmo sequencial e determinista. O algoritmo pode ser arbitrariamente complexo, mas tem que depender apenas dos argumentos da operação de transformação de dados. Em conjunto, os servidores de transformação implementam todos os aspectos algorítmicos de um sistema de software. Quando um gestor de fluxos de dados invoca uma operação de transformação, todos os dados de entrada são explicitamente passados para dentro, todos os dados de saída são explicitamente passados para fora e qualquer dado interno é explicitamente passado para dentro e para fora. Um servidor de transformação pode actualizar os dados internos apenas através dos argumentos da sua operação de transformação, mas pode não manter nenhum estado global. Um servidor de transformação nunca obtém dados de entrada directamente de um servidor de I/O, nem disponibiliza dados de saída directamente para um servidor de I/O. Gestor de fluxo de dados Os gestores de fluxos de dados são os elementos activos de um sistema. Cada um representa um fluxo independente de controlo. Os gestores de fluxos de dados são o meio através do qual um especialista em desenvolvimento de software deve implementar concorrência dentro de um sistema (excepto para os drivers de hardware). Actuam nos servidores de I/O e nos servidores de transformação através da invocação das suas operações. Um gestor de fluxo de dados efectua todas as suas acções o mais rapidamente possível. Convém sublinhar que para um gestor de fluxos de dados, esperar por entrada constitui uma acção ii. Os gestores de fluxos de dados asseguram que os fluxos de dados e os fluxos de controlo andam sempre de mão dada. Os dados são enviados e, eventualmente, retornam sempre que um gestor de fluxo de dados invoca o funcionamento de um servidor de I/O ou de um servidor de transformação. Um gestor de fluxos de dados obtém sempre dados de entrada e disponibiliza dados de saída. Nunca são enviados dados para um gestor de fluxos de dados, nem recebidos dele. Como resultado, os gestores de fluxos de dados segmentam os elementos de processamento (servidores de I/O e servidores de transformação) de um sistema e fazem com que os fluxos de dados e os fluxos de controlo sejam previsíveis e acompanháveis. Dividir para conquistar O padrão de desenho universal tem uma característica chave que o distingue de qualquer outro método de desenho ou linguagem de modelação: divide estritamente as preocupações operacionais pelos seus quatro tipos de elementos de desenho.

5 Desta forma, elimina qualquer necessidade de visualizações diferentes de um desenho. Com o padrão de desenho universal, todos os aspectos de um sistema de software podem ser representados numa única visualização. No entanto, nessa visualização cada tipo de elemento de desenho está preocupado com um e só um aspecto do funcionamento do sistema. As entidades de dados estão preocupadas apenas com estruturas de dados e operações primitivas nessas estruturas de dados. Uma entidade de dados é um objecto inteiramente passivo dado puro iii insensível a algoritmos de sistema, interfaces externas, ou sequências de acções. Os servidores de I/O estão preocupados apenas com a encapsulação e o serviço de interfaces externas (hardware). Um servidor de I/O pode estar preocupado com o tempo de I/O, mas não com o agendamento ou com a activação de outras acções de sistema. Os servidores de I/O não efectuam qualquer tarefa algorítmica relativamente aos dados de entrada ou de saída com que lidam. Os servidores de transformação estão preocupados apenas com os algoritmos do sistema. Um servidor de transformação nunca tem que se preocupar com a origem ou com o destino dos dados. Todas as operações de um servidor de transformação são sequenciais e determinísticas. Os servidores de transformação não estão preocupados com a representação dos dados, interfaces externas, ou sequências de acções. Os gestores de fluxos de dados estão preocupados apenas com os fluxos de dados e com as sequências de acções. Sabem quais as acções que o sistema precisa de realizar e em que sequência, mas não estão preocupados com os detalhes dessas acções os algoritmos e as interfaces externas (hardware). Apesar dos gestores de fluxos de dados deterem os dados internos, não estão preocupados com a sua representação. Outras abordagens de desenho esquecem normalmente os elementos de desenho que estão preocupados com múltiplos aspectos do funcionamento do sistema e que, consequentemente, têm um elevado nível de complexidade interna. Por exemplo, um desenho baseado na identificação de objectos no espaço do problema esquece frequentemente alguns elementos de desenho que estão preocupados com todos os quatro aspectos do funcionamento do sistema: estruturas de dados, interfaces externas, algoritmos e acções do sistema. Tentar tudo em conjunto Poderemos perguntar-nos como é que o padrão de desenho universal se relaciona com linguagens de desenho estabelecidas como a UML, o paradigma orientado por objectos, ou as modernas linguagens de programação. Não estamos a propor que devemos voltar as costas à orientação por objectos e restaurar a modelação de fluxo de dados. Também não estamos a dizer que devemos abandonar a UML e as abordagens baseadas em componentes. O que queremos dizer é que precisamos de utilizar essas abordagens de forma mais judiciosa. Convém recordar que cada tipo de elemento de desenho do padrão de desenho universal está preocupado apenas com um aspecto específico do funcionamento do sistema. Como tal, é perfeitamente razoável utilizar diferentes linguagens de desenho ou ferramentas de modelação para descrever cada tipo de elemento de desenho. Uma determinada linguagem de desenho ou ferramenta de modelação pode ser adequada para expressar alguns aspectos do funcionamento do sistema, mas não todos. De forma similar, uma linguagem de programação diferente pode ser mais apropriada para a implementação de cada tipo de elemento de desenho. As entidades de dados podem ser modeladas muito bem com linguagens de desenho orientadas por objectos, como a UML. Todas estas linguagens de desenho são perfeitamente capazes de representar classes, operações primitivas e relações entre classes. As entidades de dados são melhor

6 implementadas numa linguagem de programação orientada por objectos. Os servidores de I/O são melhor modelados com código estrutura de linguagem de alto nível. Tirando a UML/RT, nenhuma linguagem de desenho ou ferramenta de modelação visual chegou tão perto da descrição adequada dos aspectos de baixo nível relacionados com o hardware, com os quais um servidor de I/O tem de lidar. A Ada seria a linguagem de programação a escolher, tanto para o desenho, como para a implementação. Para descrever a arquitectura de um servidor de transformação, os gráficos de fluxos podem ser perfeitamente adequados. Na realidade, uma operação de servidor de transformação não é nada mais do que um algoritmo. Qualquer meio para descrever um algoritmo é, portanto, adequado para descrever a arquitectura de um servidor de transformação. Os servidores de transformação são melhor implementados numa linguagem de programação estruturada. Os fluxos de dados e os aspectos de interacção de objectos dos gestores de fluxos de dados podem ser modelados com praticamente qualquer linguagem de desenho. A sequência de acções efectuadas por um gestor de fluxos de dados é melhor modelada com código estrutura de linguagem de alto nível. Qualquer linguagem de programação estruturada é adequada para a implementação de um gestor de fluxo de dados. Seria interessante ter uma linguagem de desenho ou uma ferramenta de modelação que pudesse descrever visualmente a arquitectura de todo um sistema incluindo todos os tipos de elementos de desenho de uma forma uniforme. Apesar de não existir actualmente uma linguagem de desenho ou ferramenta de modelação desse tipo, existe uma linguagem de implementação que se adequa surpreendentemente bem aos elementos do padrão de desenho universal. Trata-se da linguagem Ada95 iv. Por sua vez, a popular linguagem orientada por objectos C++ apresenta fracos desempenhos quando se trata de implementar gestores de fluxos de dados e servidores de I/O. O padrão de desenho universal inspirou-se claramente nos aspectos de sistema em tempo real. Contudo, as aplicações batch sequenciais também aparecem no padrão de desenho universal como um interessante caso especial. Uma aplicação batch sequencial pode ser modelada com um servidor de transformação e qualquer número de entidades de dados, mas sem servidores de I/O ou gestores de fluxos de dados. Quanto implementamos um programa simples, estamos a implementar realmente uma transformação de dados. O programa pega em alguns dados de entrada (ficheiros de entrada), produz alguns dados de saída (ficheiros de saída) e computa dados de saída a partir de dados de entrada de acordo com um algoritmo determinístico. É exactamente isto que faz um servidor de transformação. Evidentemente, os servidores de I/O e possivelmente os gestores de fluxos de dados também estão presentes quando executamos o programa simples. No entanto, não estão representados explicitamente no desenho estão escondidos dentro do sistema operativo. Isto pode explicar porque razão as abordagens de desenho que são adequadas para as aplicações sequenciais orientação por objectos e gráficos de fluxos, por exemplo apresentam fracos desempenhos para sistemas em tempo real. Na verdade, podem funcionar bem para sistemas em tempo real se forem aplicadas apenas para os tipos certos de elementos de desenho, nomeadamente servidores de transformação e entidades de dados. A orientação por objectos e os gráficos de fluxos são, no entanto, inadequados para o desenho de gestores de fluxos de dados e de servidores de I/O. Conclusão A identificação e compreensão do princípio fundamental do desenvolvimento de software permitiu-nos definir um conjunto de regras de desenho universais o

7 padrão de desenho universal onde se devem basear todas as arquitecturas de software. Ao utilizar o padrão de desenho universal, um especialista em desenvolvimento de software deverá ser capaz de demonstrar que uma arquitectura de software é boa, sem efectuar quaisquer testes. Isto faz com que o desenho e a implementação de software seja uma actividade de engenharia previsível e repetível. Em especial, aprendemos que: O ambiente de hardware de um sistema de software não é uma limitação, mas antes uma força orientadora fundamental da arquitectura e desenho de software. É impossível criar arquitecturas de qualidade sem ter em conta o ambiente de hardware nas fases iniciais de desenho. As interacções de hardware não são uma questão de deployment e não podem ser adiadas ou ignoradas durante o desenho arquitectural. A alto nível, qualquer sistema de software pode ser modelado com quatro tipos de elementos de desenho que representam diferentes aspectos do funcionamento do sistema: estruturas de dados e operações primitivas, interfaces externas (hardware), algoritmos de sistema, fluxos de dados e sequências de acções. Nenhuma das linguagens de desenho e das ferramentas de modelação actualmente em utilização é adequada para desenvolver e representar todo um sistema de software. Existe, no entanto, uma linguagem de programação suficientemente poderosa e versátil para implementar todos os elementos e aspectos de um sistema de software. Estamos a falar da linguagem Ada. O padrão de desenho universal é verdadeiramente universal. Aplica-se a software de todos os domínios e pode ser utilizado independentemente do método de desenho ou da linguagem de modelação utilizados pelos especialistas em desenvolvimento. O estudo do padrão de desenho universal fornece uma ideia aprofundada sobre a natureza do software e do desenho de software. Baseado no artigo From Craft to Science: Rules for Software Design Part II, de Koni Buhrer, engenheiro de software na Rational Software. Tel: (+351) / 2 Fax: (+351) Internet: i A restrição da liberdade de um especialista em desenvolvimento de software seria uma ideia assustadora se o desenvolvimento de software se destinasse a permanecer uma arte ninguém quer limitar um artista. Mas se o desenvolvimento de software pretende ser uma disciplina da engenharia, então a restrição da liberdade de quem desenvolve já será uma necessidade. ii Isto pode parecer estranho, pelo que merece uma explicação. Em muitos sistemas de software que processam dados em tempo real, um servidor de entrada envia um sinal para um elemento de processamento de dados quando chegam os dados de entrada. Consequentemente, invoca o elemento de processamento de dados. O padrão de desenho universal não permite que os servidores sejam proactivos desta forma. Um gestor de fluxos de dados procede sempre através do pedido de dados de entrada ao servidor. Se o gestor de fluxos de dados quiser esperar pela chegada dos dados, então essa espera pelos dados torna-se a sua acção. Evidentemente, num nível muito baixo, um thread de servidor de I/O pode enviar um sinal para um thread de gestor de fluxos de dados para implementar a conclusão da acção

8 esperar por entrada. No entanto, não nos devemos preocupar com este tipo de detalhes de implementação no desenho arquitectural. iii A famosa excepção a esta regra sãos os ficheiros. Um objecto ficheiro tem uma interface de hardware embebida escondida. É aceitável utilizar tais entidades de dados em aplicações sequenciais. Mas em sistemas em tempo real, as entidades de dados com interfaces de hardware embebidas escondidas têm que ser estritamente evitadas. iv De facto, a linguagem Ada adequa-se tão bem que não posso acreditar que seja pura coincidência. Gostaria de perguntar aos criadores da Ada se tinham o padrão de desenho universal em mente quando criaram a linguagem Ada.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto.

Projecto de Modelação, Engenharia de Software e Sistemas Distribuídos 2008-09. Requisitos para a 3ª entrega do projecto. Departamento de Engenharia Informática Modelação, Engenharia de Software, Sistemas Distribuídos Requisitos para a 3ª entrega do projecto Test O Matic 10 de Maio de 2009 1 Índice 1 Índice... 1 2 Sumário...

Leia mais

Os Cinco Níveis de Maturidade na Gestão de Requisitos

Os Cinco Níveis de Maturidade na Gestão de Requisitos Os Cinco Níveis de Maturidade na Gestão de Requisitos Ter maturidade significa ser capaz de ver o contexto e efectuar boas escolhas. No âmbito de uma empresa, significa basear as decisões numa compreensão

Leia mais

METODOLOGIAS E PRESSUPOSTOS

METODOLOGIAS E PRESSUPOSTOS 4 METODOLOGIAS E PRESSUPOSTOS 4.1 Introdução Vimos atrás, no ponto 2.9.3, uma justificação e uma descrição resumidas dos pontos que devem ser tratados sob este tema metodologias e pressupostos a adoptar

Leia mais

Gestão de projectos na Web

Gestão de projectos na Web Gestão de projectos na Web Relatório de desenho de alto nível Versão 1.0, 5 de Maio de 2003 Telmo Pedro Gomes Amaral (mee02013@fe.up.pt) (Grupo 15) Aplicações na Web Mestrado em Engenharia Electrotécnica

Leia mais

Universidade do Minho Licenciatura em Engenharia Informática

Universidade do Minho Licenciatura em Engenharia Informática Universidade do Minho Licenciatura em Engenharia Informática Disciplina de Desenvolvimento de Sistemas de Software Trabalho Prático Fase 1 Ano Lectivo de 2009/10 GereComSaber Grupo 15 Cláudio Manuel Rigueiro

Leia mais

Eficiência e qualidade: mitos e contradições

Eficiência e qualidade: mitos e contradições 1 Eficiência e qualidade: mitos e contradições Colóquio-debate Eficiência e Justiça em Cuidados de Saúde Academia das Ciências, Lisboa, 25 de Maio de 1999 Pedro Pita Barros * 1. Introdução O tema de discussão

Leia mais

Engenharia de Software

Engenharia de Software Conceitos básicos sobre E.S: Ambiência Caracterização do software Fases de desenvolvimento 1 Introdução Aspectos Introdutórios Crise do Software Definição de Engenharia do Software 2 Crise do Software

Leia mais

Especificação Operacional.

Especificação Operacional. Especificação Operacional. Para muitos sistemas, a incerteza acerca dos requisitos leva a mudanças e problemas mais tarde no desenvolvimento de software. Zave (1984) sugere um modelo de processo que permite

Leia mais

Gestão do Risco e da Qualidade no Desenvolvimento de Software

Gestão do Risco e da Qualidade no Desenvolvimento de Software Gestão do Risco e da Qualidade no Desenvolvimento de Software Questionário Taxinómico do Software Engineering Institute António Miguel 1. Constrangimentos do Projecto Os Constrangimentos ao Projecto referem-se

Leia mais

Soluções Web Centradas no Utilizador. Ivo Gomes

Soluções Web Centradas no Utilizador. Ivo Gomes Soluções Web Centradas no Utilizador Ivo Gomes 1 Soluções Web Centradas no Utilizador Os interfaces gráficos foram desenvolvidos para dar controlo às pessoas sobre os seus computadores. Colmatar as necessidades

Leia mais

A Ergonomia e os Sistemas de Informação. Ivo Gomes

A Ergonomia e os Sistemas de Informação. Ivo Gomes A Ergonomia e os Sistemas de Informação Ivo Gomes A Ergonomia e os Sistemas de Informação Para a maior parte das pessoas, a ergonomia serve para fazer cadeiras mais confortáveis, mobiliário de escritório

Leia mais

Sistemas Distribuídos Processos I. Prof. MSc. Hugo Souza

Sistemas Distribuídos Processos I. Prof. MSc. Hugo Souza Sistemas Distribuídos Processos I Prof. MSc. Hugo Souza Até agora vimos a organização como um todo dos SDS, com o mapeamento estrutural e suas devidas características descritas em elementos, regras, conceitos,

Leia mais

Modelo Cascata ou Clássico

Modelo Cascata ou Clássico Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação

Leia mais

Notas explicativas Regras de facturação do IVA

Notas explicativas Regras de facturação do IVA Notas explicativas Regras de facturação do IVA (Directiva 2010/45/UE do Conselho) Porquê notas explicativas? O objectivo das notas explicativas é permitir uma melhor compreensão da legislação adoptada

Leia mais

Arquitecturas de Software

Arquitecturas de Software UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Mestrado em Engenharia Informática e de Computadores Primeiro Exame 21 de Janeiro de 2010, 17:00H 19:00H Nome: Número:

Leia mais

Enunciado de apresentação do projecto

Enunciado de apresentação do projecto Engenharia de Software Sistemas Distribuídos 2 o Semestre de 2009/2010 Enunciado de apresentação do projecto FEARSe Índice 1 Introdução... 2 2 Cenário de Enquadramento... 2 2.1 Requisitos funcionais...

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais

Módulo 1 Microsoft Word 2007 ( 4 Horas)

Módulo 1 Microsoft Word 2007 ( 4 Horas) No final deste módulo o formando deverá estar apto a: Enunciar a definição do Microsoft Word 2007; Reconhecer as principais vantagens da utilização; Distinguir as diferentes áreas do ambiente de trabalho

Leia mais

Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger

Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger Gerenciamento de Entrada e Saída Hélio Crestana Guardia e Hermes Senger O controle da entrada e saída (E/S ou I/O, input/output) de dados dos dispositivos é uma das funções principais de um sistema operacional.

Leia mais

CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO DE EQUIPAMENTOS INFORMÁTICOS PLANO DE ESTUDOS

CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO DE EQUIPAMENTOS INFORMÁTICOS PLANO DE ESTUDOS CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO DE EQUIPAMENTOS INFORMÁTICOS PLANO DE ESTUDOS Componentes de Formação Componente de Formação Sociocultural Português (b) Língua Estrangeira I ou II (c) Área de Integração

Leia mais

Redes de Computadores (RCOMP 2014/2015)

Redes de Computadores (RCOMP 2014/2015) Redes de Computadores (RCOMP 2014/2015) Desenvolvimento de aplicações de rede UDP e TCP 1 Protocolo UDP ( User Datagram Protocol ) Tal como o nome indica, trata-se de um serviço de datagramas, ou seja

Leia mais

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores

Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores UNIVERSIDADE TÉCNICA DE LISBOA INSTITUTO SUPERIOR TÉCNICO Arquitecturas de Software Licenciatura em Engenharia Informática e de Computadores Primeiro Teste 21 de Outubro de 2006, 9:00H 10:30H Nome: Número:

Leia mais

Programação Orientada a Objeto

Programação Orientada a Objeto Programação Orientada a Objeto Classes, Atributos, Métodos e Objetos Programação de Computadores II Professor: Edwar Saliba Júnior 1) Java é uma linguagem orientada a objetos. Para que possamos fazer uso

Leia mais

Interface Homem Máquina para Domótica baseado em tecnologias Web

Interface Homem Máquina para Domótica baseado em tecnologias Web Interface Homem Máquina para Domótica baseado em tecnologias Web João Alexandre Oliveira Ferreira Dissertação realizada sob a orientação do Professor Doutor Mário de Sousa do Departamento de Engenharia

Leia mais

O Manual do ssc. Peter H. Grasch

O Manual do ssc. Peter H. Grasch Peter H. Grasch 2 Conteúdo 1 Introdução 6 2 Usar o ssc 7 2.1 Gerir os utilizadores.................................... 7 2.1.1 Adicionar um utilizador.............................. 8 2.1.1.1 Associar-se

Leia mais

KIT CICLO PEDAGÓGICO ESTUDO DO MEIO. Propostas para planeamento, exploração e avaliação de visitas a museus e centros de ciência.

KIT CICLO PEDAGÓGICO ESTUDO DO MEIO. Propostas para planeamento, exploração e avaliação de visitas a museus e centros de ciência. KIT_PEDA_EST_MEIO_5:FERIAS_5_6 09/12/28 15:07 Page 1 1. o CICLO KIT PEDAGÓGICO Pedro Reis ESTUDO DO MEIO 5 Propostas para planeamento, exploração e avaliação de visitas a museus e centros de ciência ISBN

Leia mais

A Revolução No Seu Negócio

A Revolução No Seu Negócio A Revolução No Seu Negócio Copyright 2009 ATTRACTION MARKETING TRENDS 1 Saiba Como e Quais Os Benefícios... Lista Infinita de Contactos Marketing de Atracção Contactos Pré-Qualificados O Sistema Posiciona-o

Leia mais

Engenharia de Requisitos Estudo de Caso

Engenharia de Requisitos Estudo de Caso Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este

Leia mais

PROCESSOS DE CRIAÇÃO DE APLICATIVOS

PROCESSOS DE CRIAÇÃO DE APLICATIVOS PROCESSOS DE CRIAÇÃO DE APLICATIVOS Joaldo de Carvalho Wesley Oliveira Irlei Rodrigo Ferraciolli da Silva Rodrigo Clemente Thom de Souza INTRODUÇÃO O mundo está dominado pelos dispositivos móveis. A cada

Leia mais

Arquitecturas Tolerantes a faltas em Sistemas Distribuídos

Arquitecturas Tolerantes a faltas em Sistemas Distribuídos Arquitecturas Tolerantes a faltas em Sistemas Distribuídos Replicação de Servidores Transacções Atómicas Protocolos de Replicação Replicação passiva vs. activa Replicação de máquinas de estados vs. Replicação

Leia mais

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com

Sistemas Operacionais. Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Sistemas Operacionais Prof. André Y. Kusumoto andrekusumoto.unip@gmail.com Estruturas de Sistemas Operacionais Um sistema operacional fornece o ambiente no qual os programas são executados. Internamente,

Leia mais

ARQUITECTURA DE COMPUTADORES CAPÍTULO II AULA X

ARQUITECTURA DE COMPUTADORES CAPÍTULO II AULA X ARQUITECTURA DE COMPUTADORES CAPÍTULO II AULA X Índice Traduzindo e iniciando uma aplicação Compiladores Assembladores Linkers Loaders DLLs Iniciando um programa em Java Após toda a matéria abordada nesta

Leia mais

4.2. UML Diagramas de classes

4.2. UML Diagramas de classes Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo

Leia mais

Unified Modeling Language. Diagramas de Implementação

Unified Modeling Language. Diagramas de Implementação Unified Modeling Language Diagramas de Implementação José Correia, Junho 2006 (http://paginas.ispgaya.pt/~jcorreia/) Diagramas de implementação José Correia UML Diagramas de Implementação 2 Diagramas de

Leia mais

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual

Engenharia de Software Sistemas Distribuídos. 2º Semestre, 2007/2008. Departamento Engenharia Informática. Enunciado do projecto: Loja Virtual Engenharia de Software Sistemas Distribuídos 2º Semestre, 2007/2008 Departamento Engenharia Informática Enunciado do projecto: Loja Virtual Fevereiro de 2008 Índice Índice...2 Índice de Figuras...3 1 Introdução...4

Leia mais

Figura 5.1.Modelo não linear de um neurônio j da camada k+1. Fonte: HAYKIN, 2001

Figura 5.1.Modelo não linear de um neurônio j da camada k+1. Fonte: HAYKIN, 2001 47 5 Redes Neurais O trabalho em redes neurais artificiais, usualmente denominadas redes neurais ou RNA, tem sido motivado desde o começo pelo reconhecimento de que o cérebro humano processa informações

Leia mais

Introdução à Sistemas Operacionais. Glauber Magalhães Pires

Introdução à Sistemas Operacionais. Glauber Magalhães Pires Introdução à Sistemas Operacionais Glauber Magalhães Pires Agenda O que são sistemas operacionais? Histórico Primeira geração (1945-1955) Segunda geração (1955-1965) Terceira geração (1965-1980) Quarta

Leia mais

Introdução à Computação: Sistemas de Computação

Introdução à Computação: Sistemas de Computação Introdução à Computação: Sistemas de Computação Beatriz F. M. Souza (bfmartins@inf.ufes.br) http://inf.ufes.br/~bfmartins/ Computer Science Department Federal University of Espírito Santo (Ufes), Vitória,

Leia mais

http://www.di.uminho.pt

http://www.di.uminho.pt Escola de Engenharia Departamento de Informática Desenvolvimento de Sistemas de Informação LESI 4º ano / 2º semestre (5308O7) LMCC 4º ano / 2º semestre (7008N8 Opção II) 2005/2006 José Creissac Campos

Leia mais

Lógica para a Programação - 1º semestre AULA 01 Prof. André Moraes

Lógica para a Programação - 1º semestre AULA 01 Prof. André Moraes Pág 4 Lógica para a Programação - 1º semestre AULA 01 Prof. André Moraes 1 APRESENTAÇÃO DA UNIDADE CURRICULAR A unidade curricular de Lógica para a programação tem como objetivo promover o estudo dos principais

Leia mais

UNIVERSIDADE TÉCNICA DE MOÇAMBIQUE UDM DIRECÇÃO ACADÉMICA ÁREA DE FORMAÇÃO EM CIÊNCIAS TECNOLÓGICAS CURRÍCULO DO CURSO

UNIVERSIDADE TÉCNICA DE MOÇAMBIQUE UDM DIRECÇÃO ACADÉMICA ÁREA DE FORMAÇÃO EM CIÊNCIAS TECNOLÓGICAS CURRÍCULO DO CURSO UNIVERSIDADE TÉCNICA DE MOÇAMBIQUE UDM DIRECÇÃO ACADÉMICA ÁREA DE FORMAÇÃO EM CIÊNCIAS TECNOLÓGICAS CURRÍCULO DO CURSO LICENCIATURA EM ENGENHARIA E GESTÃO DE TECNOLOGIA DE INFORMAÇÃO E COMUNICAÇÃO ( T

Leia mais

Rock In Rio - Lisboa

Rock In Rio - Lisboa Curso de Engenharia Informática Industrial Rock In Rio - Lisboa Elaborado por: Ano Lectivo: 2004/05 Tiago Costa N.º 4917 Turma: C Gustavo Graça Patrício N.º 4757 Turma: C Docente: Professora Maria Estalagem

Leia mais

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios

GereComSaber. Disciplina de Desenvolvimento de Sistemas de Software. Sistema de Gestão de Serviços em Condomínios Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática 3ºAno Disciplina de Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/2010 GereComSaber Sistema de

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

PARLAMENTO EUROPEU. Comissão dos Assuntos Jurídicos. 10.6.2005 PE 360.003v01-00

PARLAMENTO EUROPEU. Comissão dos Assuntos Jurídicos. 10.6.2005 PE 360.003v01-00 PARLAMENTO EUROPEU 2004 ««««««««««««Comissão dos Assuntos Jurídicos 2009 10.6.2005 PE 360.003v01-00 ALTERAÇÕES 1-17 Projecto de recomendação para segunda leitura Michel Rocard Patenteabilidade das invenções

Leia mais

CASO DE ESTUDO SOBRE SIG

CASO DE ESTUDO SOBRE SIG Laboratório Regional de Engenharia Civil Agência Regional da Energia e Ambiente da Região Autónoma da Madeira Câmara Municipal do Funchal Sistema Integrado para a Implementação de Sustentabilidade CASO

Leia mais

Invenções Implementadas por Computador (IIC) Patentes

Invenções Implementadas por Computador (IIC) Patentes Invenções Implementadas por Computador (IIC) Patentes O que é uma IIC? Uma IIC é uma invenção que recorre a um computador, a uma rede de computadores ou a qualquer outro dispositivo programável (por exemplo

Leia mais

A importância do Software Livre no mundo de hoje

A importância do Software Livre no mundo de hoje A importância do Software Livre no mundo de hoje Date : 15 de Janeiro de 2014 Por Luis da Costa para o Pplware! Uma questão de conceitos, termos e liberdades. Uma das grandes e mais importantes temáticas

Leia mais

Micro Mídia Informática Fevereiro/2009

Micro Mídia Informática Fevereiro/2009 Micro Mídia Informática Fevereiro/2009 1 UML Introdução Fases de Desenvolvimento Notação Visões Análise de Requisitos Casos de Uso StarUML Criando Casos de Uso Orientação a Objetos Diagrama de Classes

Leia mais

PERFIL PROFISSIONAL PROGRAMADOR(A) DE INFORMÁTICA. PERFIL PROFISSIONAL Programador/a de Informática Nível 3 CATÁLOGO NACIONAL DE QUALIFICAÇÕES 1/5

PERFIL PROFISSIONAL PROGRAMADOR(A) DE INFORMÁTICA. PERFIL PROFISSIONAL Programador/a de Informática Nível 3 CATÁLOGO NACIONAL DE QUALIFICAÇÕES 1/5 PERFIL PROFISSIONAL PROGRAMADOR(A) DE INFORMÁTICA PERFIL PROFISSIONAL Programador/a de Informática Nível 3 CATÁLOGO NACIONAL DE QUALIFICAÇÕES 1/5 ÁREA DE ACTIVIDADE OBJECTIVO GLOBAL SAÍDA(S) PROFISSIONAL(IS)

Leia mais

Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia

Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia Instituto Superior Politécnico Gaya Escola Superior de Ciência e Tecnologia Engenharia Informática Interligação e Gestão de Sistemas Informáticos 2006/2007 Interface WEB para Gestão de Máquinas Virtuais

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Processos I: Threads, virtualização e comunicação via protocolos Prof. MSc. Hugo Souza Nesta primeira parte sobre os Processos Distribuídos iremos abordar: Processos e a comunicação

Leia mais

Aplicação de Estatísticas de Ensino Superior

Aplicação de Estatísticas de Ensino Superior Instituto Politécnico de Beja Escola Superior de Tecnologia e Gestão Curso de Engenharia Informática Disciplina de Linguagens de Programação Aplicação de Estatísticas de Ensino Superior Linguagem: Python

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

UML jvo. 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa;

UML jvo. 1. Disponibilizar uma linguagem de modelação visual expressiva e rigorosa; UML A Unified Modeling Language (UML) é uma linguagem, essencialmente gráfica, para modelar, especificar e documentar elementos de sistemas, não necessariamente informáticos. É um standard reconhecido

Leia mais

Guia da Internet. Página 1

Guia da Internet. Página 1 Guia da Internet Utilização da Internet Introdução... 2 Alguns conceitos básicos... 2 Endereços (URL)... 2 Páginas Web... 3 Abrir o Internet Explorer... 3 O ecrã do Internet Explorer... 4 A Barra de Ferramentas

Leia mais

MODELAGEM DE SISTEMA Apresentação

MODELAGEM DE SISTEMA Apresentação MODELAGEM DE SISTEMA Apresentação Prof Daves Martins Msc Computação de Alto Desempenho Email: daves.martins@ifsudestemg.edu.br Apresentação da Disciplina Apresentação da Disciplina Apresentação da Disciplina

Leia mais

Aspectos de Sistemas Operativos

Aspectos de Sistemas Operativos Paulo Sérgio Almeida Grupo de Sistemas Distribuídos Departamento de Informática Universidade do Minho Serviços de um sistema operativo Interface com o utilizador Chamadas ao sistema Programas de sistema

Leia mais

2 Engenharia de Software

2 Engenharia de Software 20 2 Engenharia de Software 2.1 Design de Sistemas Orientados a Objetos Os Sistemas Orientados a Objetos não são mais novidade hoje em dia já estando há muitos anos no mercado. A orientação a objetos permite

Leia mais

Aspectos Sócio-Profissionais da Informática

Aspectos Sócio-Profissionais da Informática ESCOLA SUPERIOR DE TECNOLOGIA I N S T I T U T O P O L I T É C N I C O D E C A S T E L O B R A N C O ENGENHARIA INFORMÁTICA Aspectos Sócio-Profissionais da Informática Jovens Empresários de Sucesso e Tendências

Leia mais

Figura 5 - Workflow para a Fase de Projeto

Figura 5 - Workflow para a Fase de Projeto 5. Fase de Projeto A Fase de Projeto caracteriza-se por transformar as informações modeladas durante a Fase de Análise em estruturas arquiteturais de projeto com o objetivo de viabilizar a implementação

Leia mais

27. Organize o seu Espaço de Trabalho: Ficheiros Electrónicos... 46 28. Organize o seu Espaço de Trabalho: Contactos 47 29. Organize o seu Espaço de

27. Organize o seu Espaço de Trabalho: Ficheiros Electrónicos... 46 28. Organize o seu Espaço de Trabalho: Contactos 47 29. Organize o seu Espaço de ÍNDICE Como usar este livro 13 Introdução: Este livro pode poupar-lhe tempo! 15 l. O Difícil É Começar 17 2. Elabore um Estudo do Tempo 18 3. Defina as Áreas Problemáticas... 19 4. Estabeleça Objectivos

Leia mais

COMPOSIÇÃO AUDIO VISUAL ALGORÍTMICA ESTOCÁSTICA: 'GERAR E ORGANIZAR VARIEDADE'

COMPOSIÇÃO AUDIO VISUAL ALGORÍTMICA ESTOCÁSTICA: 'GERAR E ORGANIZAR VARIEDADE' P R O P O S T A D E T R A B A L H O Unidade Curricular Laboratório Multimedia - LM301 COMPOSIÇÃO AUDIO VISUAL ALGORÍTMICA ESTOCÁSTICA: 'GERAR E ORGANIZAR VARIEDADE' ANDRÉ RANGEL MACEDO DOUTORANDO E INVESTIGADOR

Leia mais

3.1 Definições Uma classe é a descrição de um tipo de objeto.

3.1 Definições Uma classe é a descrição de um tipo de objeto. Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Classes Autoria:Aristófanes Corrêa Silva Adaptação:

Leia mais

IMPLEMENTAÇÃO DE UM SISTEMA DE SELEÇÃO DE PEÇA USANDO CONCEITOS DE PROGRAMAÇÃO DE SISTEMA DE AUTOMAÇÃO. João Alvarez Peixoto*

IMPLEMENTAÇÃO DE UM SISTEMA DE SELEÇÃO DE PEÇA USANDO CONCEITOS DE PROGRAMAÇÃO DE SISTEMA DE AUTOMAÇÃO. João Alvarez Peixoto* IMPLEMENTAÇÃO DE UM SISTEMA DE SELEÇÃO DE PEÇA USANDO CONCEITOS DE PROGRAMAÇÃO DE SISTEMA DE AUTOMAÇÃO João Alvarez Peixoto* * Mestrando do Programa de Pós-graduação em Engenharia Elétrica - UFRGS Porto

Leia mais

CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS TURMA 2008/1 4º PERÍODO 7º MÓDULO AVALIAÇÃO A3 DATA 15/10/2009 ENGENHARIA DE SOFTWARE 2009/2 GABARITO COMENTADO QUESTÃO 1: Analise as afirmações

Leia mais

Conference For You C4U v. 0.13

Conference For You C4U v. 0.13 Departamento de Informática Conference For You C4U v. 0.13 Projecto Integrador 2012/2013 Licenciatura em Engenharia Informática Preparado por: João Regateiro nº 28994 Miguel Silva nº 28508 Ricardo Monteiro

Leia mais

3 ao Quadrado - Agenda Web

3 ao Quadrado - Agenda Web 3 ao Quadrado - Agenda Web Relatório de Gestão de Projectos de Software - Grupo A - LEIC 2001/2002 http://gnomo.fe.up.pt/gps01a João Montenegro - ei97023@fe.up.pt André Teixeira - ei97024@fe.up.pt Carlos

Leia mais

CAPÍTULO V CONCLUSÕES, IMPLICAÇÕES E SUGESTÕES

CAPÍTULO V CONCLUSÕES, IMPLICAÇÕES E SUGESTÕES CAPÍTULO V CONCLUSÕES, IMPLICAÇÕES E SUGESTÕES 5.1. Introdução Neste último capítulo, pretendemos esboçar as principais conclusões sobre os resultados obtidos na investigação orientada para o objectivo

Leia mais

OCL: Object Constraint Language

OCL: Object Constraint Language OCL: Amílcar Domingos Rodrigues Santy Fernandes, Girson César Silva Monteiro, Rui Sá Guerra, Simão Castro Faculdade de Engenharia da Universidade Do Porto, Rua Dr. Roberto Frias, s/n 4200-465 Porto, Portugal

Leia mais

Algoritmos e Programação Parte Teórica

Algoritmos e Programação Parte Teórica Universidade Federal do Vale do São Francisco Curso de Engenharia da Produção / Elétrica Algoritmos e Programação Parte Teórica Prof. Jorge Cavalcanti jorge.cavalcanti@univasf.edu.br www.univasf.edu.br/~jorge.cavalcanti

Leia mais

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br Introdução O computador como ferramenta indispensável: Faz parte das nossas vidas; Por si só não faz nada de útil; Grande capacidade de resolução

Leia mais

Análise de Sistemas. Conceito de análise de sistemas

Análise de Sistemas. Conceito de análise de sistemas Análise de Sistemas Conceito de análise de sistemas Sistema: Conjunto de partes organizadas (estruturadas) que concorrem para atingir um (ou mais) objectivos. Sistema de informação (SI): sub-sistema de

Leia mais

CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO E PROGRAMAÇÃO DE SISTEMAS INFORMÁTICOS

CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO E PROGRAMAÇÃO DE SISTEMAS INFORMÁTICOS CURSO PROFISSIONAL DE TÉCNICO DE GESTÃO E PROGRAMAÇÃO DE SISTEMAS INFORMÁTICOS PLANO DE ESTUDOS Componentes de Formação Total de Horas (a) (Ciclo de Formação) Componente de Formação Sociocultural Português

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Ferramenta de Apoio ao Jogo 2 (Ensino da Leitura) incluído nos Jogos da Mimocas

Ferramenta de Apoio ao Jogo 2 (Ensino da Leitura) incluído nos Jogos da Mimocas As Palavras Ferramenta de Apoio ao Jogo 2 (Ensino da Leitura) incluído nos Jogos da Mimocas 1. Introdução A Associação Portuguesa de Portadores de Trissomia 21 (APPT21) e a Escola Superior de Gestão de

Leia mais

Mapa Mental de Engenharia de Software - Diagramas UML

Mapa Mental de Engenharia de Software - Diagramas UML Mapa Mental Engenharia Software - Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental Engenharia Software Diagramas UML Mapa Mental UML - Diagramas, Fases e Detalhes Resolvi juntar

Leia mais

3. Engenharia de Requisitos

3. Engenharia de Requisitos Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton)

Leia mais

GRUPO DE TRABALHO DE PROTECÇÃO DE DADOS DO ARTIGO 29.º

GRUPO DE TRABALHO DE PROTECÇÃO DE DADOS DO ARTIGO 29.º GRUPO DE TRABALHO DE PROTECÇÃO DE DADOS DO ARTIGO 29.º 00327/11/PT WP 180 Parecer 9/2011 sobre a proposta revista da indústria relativa a um quadro para as avaliações do impacto das aplicações RFID na

Leia mais

Guia de utilização da notação BPMN

Guia de utilização da notação BPMN 1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação

Leia mais

Entradas/Saídas. Programação por espera activa Programação por interrupções

Entradas/Saídas. Programação por espera activa Programação por interrupções Entradas/Saídas Programação por espera activa Programação por interrupções Programação por espera activa 1. O programa lê o estado do periférico: CPU pede ao controlador (IN) o valor no registo ESTADO

Leia mais

PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO (PROENG) ASSESSORIA DE DESENVOLVIMENTO ASSESSORIA JURÍDICA

PRÓ-REITORIA DE ENSINO DE GRADUAÇÃO (PROENG) ASSESSORIA DE DESENVOLVIMENTO ASSESSORIA JURÍDICA FORMULÁRIO DE ALTERAÇÃO DE EMENTAS CURSO: SISTEMAS DE INFORMAÇÃO MATRIZ(ES) CURRICULAR(ES): 2011 ALTERAÇÕES PASSAM A VIGORAR A PARTIR DO SEMESTRE: 2015.1 Banco de Dados I Estudo dos aspectos de modelagem

Leia mais

Introdução a Informática. Prof.: Roberto Franciscatto

Introdução a Informática. Prof.: Roberto Franciscatto Introdução a Informática Prof.: Roberto Franciscatto APRESENTAÇÃO Os computadores chegaram aos diversos níveis das organizações Nestes contexto: Que linguagem entendem? Que produtos podem usar? Dúvidas

Leia mais

Política de Privacidade da Plataforma Comercial de Viagens Travelport para o GDS

Política de Privacidade da Plataforma Comercial de Viagens Travelport para o GDS Política de Privacidade da Plataforma Comercial de Viagens Travelport para o GDS Bem-vindo/a a este website da Travelport. Na Travelport reconhecemos a importância de proteger a privacidade dos dados pessoais

Leia mais

Plataforma integrada para testes em arquitecturas orientadas a serviços

Plataforma integrada para testes em arquitecturas orientadas a serviços Plataforma integrada para testes em arquitecturas orientadas a serviços Índice Introdução... 2 A solução... 2 Plataforma Integrada (principais características)... 4 Eliminar limitações à execução de testes

Leia mais

Diagramas de Casos de Uso

Diagramas de Casos de Uso UML Unified Modeling Language Diagramas de Casos de Uso José Correia, Março 2006 (http://paginas.ispgaya.pt/~jcorreia/) Objectivos O objectivo de um diagrama de casos de uso de um sistema é mostrar para

Leia mais

Rentabilize a sua assistência pós-venda e, em simultâneo, surpreenda os seus clientes com o seu profissionalismo

Rentabilize a sua assistência pós-venda e, em simultâneo, surpreenda os seus clientes com o seu profissionalismo PHC Suporte CS DESCRITIVO O PHC Suporte CS permite a qualquer empresa com assistência a clientes pós-venda, gerir todo o seu parque instalado, a actividade de suporte ao público e a performance e produtividade

Leia mais

COMPETÊNCIAS BÁSICAS EM TIC NAS EB1. Oficina da Internet

COMPETÊNCIAS BÁSICAS EM TIC NAS EB1. Oficina da Internet COMPETÊNCIAS BÁSICAS EM TIC NAS EB1 Oficina da Internet Utilização Educativa da Internet Guião de iniciação à consulta e pesquisa de informação na Web Índice Introdução... 2 Alguns conceitos básicos...2

Leia mais

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW

Aula 2 Revisão 1. Ciclo de Vida. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW. Processo de Desenvolvimento de SW Ciclo de Vida Aula 2 Revisão 1 Processo de Desenvolvimento de Software 1 O Processo de desenvolvimento de software é um conjunto de atividades, parcialmente ordenadas, com a finalidade de obter um produto

Leia mais

Programação de. Programa. Bibliografia. Páginas electrónicas de PM. Regras das aulas de laboratório. Métodos de Ensino - Aulas

Programação de. Programa. Bibliografia. Páginas electrónicas de PM. Regras das aulas de laboratório. Métodos de Ensino - Aulas Programa Programação de Microprocessadores 1º Ano 2º Semestre A arquitectura dos computadores A linguagem C 1 aula 7 aulas Talvez haja mais algum assunto a abordar nas aulas seguintes Mestrado Integrado

Leia mais

Política Anti-Suborno da ADP Questões Frequentes (FAQs)

Política Anti-Suborno da ADP Questões Frequentes (FAQs) Política Anti-Suborno da ADP Questões Frequentes (FAQs) AS COMUNICAÇÕES ENTRE ADVOGADO E CLIENTE SÃO ESTRITAMENTE CONFIDENCIAIS Este documento destina-se a abordar questões que possam surgir no decurso

Leia mais

4. PRINCÍPIOS DE PLANEAMENTO DE RECURSOS HÍDRICOS

4. PRINCÍPIOS DE PLANEAMENTO DE RECURSOS HÍDRICOS 4. PRINCÍPIOS DE PLANEAMENTO DE RECURSOS HÍDRICOS A abordagem estratégica que se pretende implementar com o Plano Regional da Água deverá ser baseada num conjunto de princípios nucleares que, sendo unanimemente

Leia mais

Estrutura de um Sistema Linux Moderno Padrões de um Sistema Linux. Prof. Claudio Silva

Estrutura de um Sistema Linux Moderno Padrões de um Sistema Linux. Prof. Claudio Silva Estrutura de um Sistema Linux Moderno Padrões de um Sistema Linux Estrutura de um Sistema Linux Por ter sua origem universitária, a forma como o Linux foi concebido é de perfeito agrado para o seu estudo.

Leia mais

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr Metodologia de Desenvolvimento de Software Prof. M.Sc. Sílvio Bacalá Jr Objetivos Discutir aspectos de Engenharia de Software Aplicar um método de desenvolvimento para especificação e projeto de software

Leia mais

Engenharia de Requisitos de Software

Engenharia de Requisitos de Software Engenharia de Requisitos de Software Marcelo Otone Aguiar, MSc, PMP PROJETOS 1 O que é Projeto Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. PMI

Leia mais

Introdução sobre o Tempo Real

Introdução sobre o Tempo Real Capítulo 1 Introdução sobre o Tempo Real Esse capítulo visa esclarecer o entendimento de tempo real dos autores, definir conceitualmente os Sistemas de Tempo Real e apresentar os problemas e desafios que

Leia mais