Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case
|
|
- Jónatas Machado Sanches
- 8 Há anos
- Visualizações:
Transcrição
1 Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case Luiz Henrique Martins Lins Rolim Instituto Tecnológico de Aeronaútica ITA- São José dos Campos SP (Times New Roman, size 9) Bolsista PIBIC-CNPq Professor orientador : José Maria Parente de Oliveira instituto Tecnológico de Aeronaútica ITA- São José dos Campos SP (Times New Roman, size 9) parente@ita.br Resumo: Esse artigo propõe a utilização de mapas conceituais (CMAP) como elemento integrante do processo de engenharia de software, mais especificamente na fase de levantamento de requisitos do sistema, por possibilitar um excelente canal de comunicação entre os conceitos que compõe o domínio do sistema e os elementos que irão compor a solução no nível operacional. Como estudo de caso, foi selecionado, devido ao acesso irrestrito à documentação, e a complexidade relativamente simples, o software em desenvolvimento na disciplina de graduação CES-31. Esse software, a metodologia CRC/WB+, utilizada no processo de modelagem, e os resultados que demonstram a viabilidade da utilização dos CMAPS serão detalhados ao longo do artigo. 1-Introdução: O levantamento de requisitos constitui uma etapa imprescindível da engenharia de software e muitos problemas decorrem da imprecisão na especificação de requisitos[sommerville-2005]. Esse levantamento deve ser realizado reuniões com os o(s) cliente(s), e com todos aqueles que possuírem conhecimento sobre o domínio; a esse conjunto de usuários denomina-se genericamente stakeholders. Os requisitos do software devem ser especificados de modo a atender o desejo dos usuários finais, que podem possuir diferentes pontos de vista em relação à utilização do sistema [Sommerville-2005]. Os stakeholders tendem a descrever requisitos segundo objetivos pessoais ou políticos, ou seja o que eles gostariam que o software realizasse para proveito pessoal e esses tendem a não representarem o que o sistema deveria fazer na realidade, não são passíveis de implementação, ou contém fatores políticos ou organizacionais[sommerville-2005]. Seria ideal, portanto que o engenheiro de requisitos possuísse total conhecimento sobre o domínio do sistema uma vez que isso geraria maiores possibilidades de comunicação com os stakeholders na fase de levantamento de requisitos, o que implicaria em requisitos melhores especificados e conseqüente ganho de produtividade no processo de engenharia de software como um todo. Na prática, contudo é impossível que o engenheiro de software chegue ao menos perto de conhecer tudo acerca dos domínios em que ele trabalha, por mais que ele possua anos de experiência.obviamente, alguns sistemas possuem boa parte de seu sistema como de conhecimento público e isso pode contribuir com o aumento de produtividade do processo. Como exemplo, considere um sistema de controle de vendas em um supermercado. Um engenheiro de requisitos irá desconfiar se um caixa desejar que o sistema lhe dê condições de alterar o montante da venda num determinado dia; entretanto, esse mesmo engenheiro provavelmente não teria condições de inferir se em um sistema de perfuração de petróleo o operador deveria ter ou não acesso ao montante retirado de um poço de petróleo em um determinado período de tempo. Além de um melhor levantamento de requisitos, uma maior compreensão do domínio do sistema poderá auxiliar o engenheiro de software, em sistemas OO, a realizar mais facilmente a transição entre a perspectiva conceitual do sistema para a perspectiva de software, etapa que é conhecida segundo a metodologia CRC/WB+ como FEI (Fase Exploratória Inicial). Ferramentas CASE podem ser utilizadas, nesse contexto, a fim de possibilitar ao engenheiro de software aumentar sua compreensão sobre o domínio do sistema. A utilização de diagramas de classe a nível conceitual, como modo de auxiliar o conhecimento do domínio do aplicativo, já é defendida por alguns autores na fase de especificação de requisitos [COCKBURN 2000] [Fowler 2003]. Entretanto, ao utilizar notações em UML no nível conceitual o engenheiro corre o risco de contaminar o vocabulário do domínio com termos técnicos o que dificultaria o diálogo com os stakeholders [Inaldo 2005].
2 Uma alternativa seria adotar notações externas a UML nesta fase conceitual. A vantagem desta outra abordagem é poder optar por representações próximas a maneira de pensar dos usuários. O problema que poderia advir com esta abordagem é tornar difícil a transição entre a Perspectiva Conceitual e a Perspectiva de Software [Costa 2005]. Assim, faz-se necessária à utilização de uma ferramenta que possibilite um bom diálogo com os stakeholders e que facilite a transição para a perspectiva de software. Esse artigo defende a utilização de mapas conceituais (do inglês CMAPs) como sendo uma ferramenta que atende as expectativas expostas acima e terá suas conclusões baseadas em um estudo de caso simples que foi desenvolvido no curso de graduação de CES-31 do ITA. O texto é composto de uma parte mais teórica, a seção 2, onde será definido o que é um Mapa Conceitual, a seção 3 onde será feita uma pequena introdução dos conceitos OO, a seção 4 que irá introduzir os conceitos necessários referentes à metodologia CRC/WB+, e uma parte mais prática, composta pela seção 5, onde será apresentado o Estudo de Caso e a seção 6 com as respectivas conclusões. 2-Mapas Conceituais : Mapa conceitual é uma ferramenta de representação de conhecimento[novak,1998]. O aspecto principal de um mapa conceitual é a representação de relações entre conceitos de um corpo de conhecimento. Embora normalmente incluam uma organização hierárquica e, muitas vezes, incluam setas, tais diagramas não devem ser confundidos com organogramas ou diagramas de fluxo, pois não implicam seqüência, temporalidade ou direcionalidade nem hierarquias organizacionais ou de poder. Mapas conceituais são diagramas de significados, de relações significativas, de hierarquias conceituais, se for o caso [Moreira 1997]. Um mapa conceitual deve servir para capturar o maior número possível de informações sobre um determinado domínio. Considere o mapa conceitual abaixo construído para representar o domínio dos números primos: Figura 1: Mapa conceitual números primos. Observe que neste mapa, diferentemente dos diagramas UML convencionais o objetivo é ter uma idéia sobre o domínio do problema a ser resolvido o que possibilita uma linguagem simples que pode ser compreendida mesmo por usuários que não possuam quaisquer familiaridades com programação. Desta
3 forma, um mapa conceitual pode servir como uma transição, em termos de documentação, para diagramas de classe UML padrão, possibilitando ao engenheiro de software aproximar-se ao máximo da visão do usuário sem, contudo dificultar suas tarefas posteriores. Na construção do mapa, devem ser levantada a maior quantidade possível de informação sobre o sistema, independente se essas serão ou não utilizadas. Em uma etapa posterior à construção, será realizada análise de quais dos conceitos são ou não pertinentes aquele sistema específico. Os conceitos devem ser escritos de forma a possibilitar uma fácil comunicação com o cliente. Eles não devem conter, portanto, quaisquer terminologias especificas de engenharia de software. 2.1-Recomendações de construção: As recomendações abaixo visam padronizar os mapas conceituais de modo a facilitar a construção e execução do algoritmo apresentado em 5.3. Evitar a utilização de verbos como conceitos dos mapas. Eles devem ser preferencialmente substantivos não flexionados. Evitar a utilização de substantivos nas relações entre conceitos. Elas devem ser preferencialmente verbos no infinitivo. Evitar a utilização de conceitos sinônimos. Atentar quanto à representação de relações condicionais. É desejável estabelecer relações utilizando o menor número de conceitos possíveis. Utilizar o menor número de verbos nas relações entre conceitos. 3-Conceituação fundamental sobre Linguagens OO : Com intuito de facilitar o entendimento dos itens subseqüentes deste relatório será apresentada uma conceituação à cerca de alguns dos principais conceitos pertinentes as linguagens OO. 3.1-Abstração: O termo abstração diz respeito à capacidade de extrair de um objeto do mundo real os principais valores ou ações que ele desempenha ou, mais especificamente, aqueles valores ou ações que devem ser levados em conta no domínio da aplicação e é fundamental no processo de aprendizado e de modelagem de linguagens OO bem como nas demais cadeiras de computação. O primeiro passo na construção de um algoritmo é a abstração do problema real nas entidades que compõe a linguagem OO. Um aluno iniciante terá dificuldades em delimitar quais os objetos reais que devem ou não ser representados computacionalmente em termos das entidades OO e quais são as ações e propriedades que essas necessitam para funcionar corretamente. Um mesmo objeto real pode ser representado de inúmeras maneiras dependendo do problema em que ele está inserido. As representações de um carro, por exemplo, serão, com certeza, diferentes em um software que simula as forças que estão aplicadas à estrutura do chassi e em um jogo de corrida. Essas diferenças devem ser levadas em conta pelo engenheiro de software na hora de modelar o seu sistema. 3.2-Classes: As classes são a estrutura básica de qualquer linguagem OO. Uma classe será definida a partir do processo de abstração de um objeto real e nela estarão descritas todas as ações e propriedades desse que interessam ao contexto do sistema. Compete ao engenheiro de software ou programador decidir quais objetos reais necessitam ser representados em classes. Apesar de poder haver algumas interseções nos objetivos de diferentes classes, essas possuirão, em geral, diferentes propriedades (atributos) e responsabilidades (métodos) no domínio do sistema. Um método comum a todas as classes é o construtor sendo esse utilizado para criar um objeto daquela classe. Para exemplificação consideremos um software de jogo xadrez. Possíveis classes seriam o tabuleiro, as peças, a tela, os jogadores e talvez uma classe de controle. A classe de peças pode possuir propriedades como cor, posição atual no tabuleiro, tipo e métodos como movimento, captura, etc. 3.3-Objetos:
4 Conforme visto acima as classes formam um protótipo de um objeto do mundo real, definindo todas as características desse que interessam ao domínio da aplicação. Um objeto, por sua vez, é uma ocorrência (instância) ou exemplo específico de uma classe. Os objetos serão os responsáveis por, de fato, utilizar as propriedades das classes. Um objeto é instanciado quando da chamada do método (obrigatório) construtor da classe. Vários objetos da mesma classe podem ser necessários em um determinado domínio. No exemplo do jogo de xadrez, teríamos dezesseis objetos da classe peão, (oito para cada jogador); na modelagem de um carro, dependendo do objetivo do software, talvez fossem necessários 4 objetos da classe roda; em um jogo de videogame vários objetos da classe monstro poderiam ser necessários, etc. 3.4-Herança: Herança em OO é uma característica que permite um relacionamento entre classes de modo que uma classe, denominada classe base, tenha seus métodos e atributos aproveitados (herdados) por outras classes, denominados classes derivadas. Essa hierarquia é fundamental por permitir um reaproveitamento de código, tornando-o mais organizado além facilitar o processo de abstração, já que no mundo real, muitos objetos podem ser relacionados hierarquicamente. Para um exemplo de herança, considere a classe cão. Possíveis classes derivadas seriam poodle, viralatas, etc. Como exemplo de herança pertinente ao mundo da programação, mais especificamente na linguagem C#, podemos citar os formulários do Windows (Windows Forms) como Caixas de Texto ou Botões que são herdadas a partir de uma classe comum chamada Form. 4-Rápida Introdução à metodologia CRC\WB+ A metodologia CRC\WB+ é uma metodologia de engenharia de software que objetiva documentar o software através de um processo interativo e incremental. Ela foi desenvolvida pelo professor doutor Clóvis Torres Fernandes e é lecionada no curso de graduação de CES-31 (Engenharia de Software) no instituto tecnológico de aeronáutica ITA. A metodologia é constituída de diversas fases mas apenas duas são relevantes no contexto do artigo, a LPR (levantamento preliminar de requisitos) e a FEI (fase exploratória inicial). 4.1-Levantamento Preliminar de Requisitos (LPR) Na fase LPR são levantados os requisitos do sistema. Ela é constituída, basicamente, pelas seguintes etapas: Descrição Textual do Software: Nessa etapa o software é descrito sob linguagem natural do ponto de vista dos usuários do sistema. O texto deve ser livre de ambigüidades e omissões de modo a introduzir suas principais funcionalidades. Levantamento de Requisitos: Nessa fase serão levantados tanto os requisitos funcionais quanto os não funcionais. Os requisitos principais já foram destacados a partir da descrição textual mas, requisitos adicionais podem ser acrescentados. Todos os requisitos que forem levantados são ordenados, quanto ao grau de importância (essencial ou secundário) e de necessidade (necessário, desejável, opicional) Confecção do Manual Preliminar do Usuário Trata-se de um protótipo do sistema que irá detalhar ao usuário as funcionalidades das telas do sistema. Determinação do Diagrama de Arquitetura Distribuída (DAD) Nesta etapa será construído o diagrama de arquitetura distribuída que indica quem são os atores e os sistemas presentes no software. O software pode ser divido em subsistemas que denominam-se, genericamente, visões focais. Levantamento dos casos de Uso Com base nas funcionalidades que foram levantadas na etapa Levantamento de Requisitos serão levantados os casos de uso do sistema. Estes devem ser descritos sobre a forma de templates que fornecem um grande número de detalhes a cerca de sua estrutura e de seu curso de eventos típicos Fase Exploratória Inicial (FEI) :
5 Na fase FEI o software será dividido em quatro camadas e será descrito, mediante a utilização de cartões CRC, em classes para cada uma de suas camadas. Ela é constituída, basicamente, pelas seguintes etapas: Identificação de Classes de Regras de Negócio (RN) A camada de regras de negócio é responsável por realizar o interfaceamento entre a camada de interface do usuário (IU) e as camadas de persistência (IP) ou do sistema operacional (SO). Ela contém a maior parte da lógica por trás do aplicativo. Segundo a metodologia CRC/WB+ essas classes serão levantadas a partir da análise dos casos de uso levantados na LPR. Identificação de Classes de Interface de Usuário (IU) As classes de interface de usuário são as telas presentes nos sistemas que compõe o software. Nessa etapa da FEI, devem ser especificadas a finalidade, as responsabilidades e as colaborações de cada classe e possivelmente as estruturas de dados que elas utilizarão. Definição de Classe da Interface de Persistência Essas classes são as responsáveis por estabelecer um protocolo de armazenamento e recuperação de informações. Nesta fase serão definidas como será realizada essa comunicação. Definição de Classes de Interface com o Sistema Operacional Essas classes possibilitam a comunicação do software com recursos do sistema operacional, como drivers, portas, formas de comunicação, etc. Nesta fase estas classes devem ser descritas em termos de responsabilidades e atributos. Definição da lógica das Responsabilidades Nesta fase será descrita a lógica existente nas responsabilidades de cada uma das classes identificadas nas etapas anteriores. A partir dessa decrição será possível a identificação de novas classes e colaborações. 5-Estudo de Caso: Jogo de Xadrez à Australiana 5.1 Descrição Narrativa: O projeto consiste em uma variante do jogo de xadrez adaptado para dois times de duas pessoas cada, que jogarão em modo cooperativo, e é popularmente conhecida como Australiana. Inicialmente, duas duplas são formadas. Dentro de cada dupla há um sorteio de forma que em cada time haja uma pessoa jogando com as peças pretas e outro com as brancas. Feito isso, haverá um cruzamento das duplas de modo que o membro de brancas de uma dupla jogará, simultaneamente, e em dois tabuleiros distintos, com o de pretas da outra e vice-versa. Cada tabuleiro terá seu relógio próprio, e cada jogador seu próprio tempo. O jogo acaba quando um jogador levar um xeque-mate ou acabar seu tempo, ocasionando a derrota de sua dupla. A cooperação entre os jogadores da mesma dupla dá-se de modo que todas as peças que são capturadas por um jogador poderão ser usadas pelo outro jogador da dupla. Um jogador em seu turno pode optar por colocar em seu tabuleiro qualquer uma das peças fornecidas, ou realizar uma jogada convencional. Não há, portanto, necessidade de se colocar as peças em jogo, nem qualquer tipo de ordem que precisa ser seguida para inserir as peças no tabuleiro. Existem, entretanto, as seguintes restrições para a entrada de uma peça: - Peões não podem entrar nem na primeira, nem sétima, nem oitava fileiras; - Peças não podem entrar colocando o rei do adversário em xeque. - Peças devem entrar em casas vazias. O jogo deve usar relógios para prevenir que os jogadores esperem indefinidamente por uma peça (esperar por uma peça é considerado perfeitamente aceitável). Há diversas opiniões, mas geralmente é aceitável diálogo entre companheiros de time. Um jogador pode pedir peças específicas para colocar em seu tabuleiro, de forma a evitar ou conseguir um mate. (essa é uma das características mais legais desse jogo, a dinâmica). Será armazenado em um banco de dados, o perfil de cada usuário com o número de vitórias, empates, derrotas, além da cor utilizada para jogar e seu ranking.
6 5.2- Perspectiva do usuário: Mapa conceitual do Jogo de Xadrez à Australiana figura 1 : Mapa conceitual Extraindo Classes e Responsabilidades a Partir do CMAP Construído o mapa conceitual, é possível inferir prováveis classes e responsabilidades do sistema. Para essa identificação, proponho as etapas: 1. Tabelar todos os conceitos do mapa, retirando-lhes os numerais, artigos e declinações de número e grau quando substantivos. Os verbos serão marcados como métodos. 2. Definir nesta tabela os conceitos pai. Conceitos que não possuírem conceito pai, serão marcados como entidades representativas do sistema e não precisarão ser analisados em 3 e 4.
7 3. Definir nesta tabela o tipo dos verbos que dos conectores de entrada e de saída do conceito segundo regra abaixo: Verbos de ação(definir,tornar,utilizar,poder,etc...) representam responsabilidades do sistema Verbos de composição (possuir, compor,ter,etc...) representam relações de pertinência entre conceitos Verbos de ligação (ser,estar) representam estados que um determinado conceito pode alcançar no programa. Conectivos relacionais (conforme,segundo,) representam relações entre conceitos que não podem ser inferidas. No caso, de um conceito possuir conectivos relacionais de entrada, devemos subir um nível no mapa em relação ao seu conceito pai. Outros tipos serão marcados como entidade. 4. Para cada um dos conceitos tabelados em 1, identificar os tipos de verbo de saída, segundo critério abaixo. Marcar conceitos que possuírem verbos de ação entre os seus conectivos como prováveis classes, uma vez que possuem responsabilidades atribuídas. Marcar conceitos que não possuírem verbos de ação, mas possuírem verbos de ligação entre os seus conectivos como atributos Marcar conceitos que possuírem verbos de composição como classes. 5. Para cada um dos conceitos tabelados em 1, identificar os tipos de verbo de entrada, segundo critério abaixo: Marcar os conceitos definidos como classe em 3 e que possuírem verbo de composição no conectivo chegando nele, como subclasse do conceito pai. Marcar os conceitos definidos como atributos em 3 e que possuírem verbo de verbo de composição em algum conectivo, como atributo do conceito pai. Marcar os conceitos que possuírem verbo de ligação em algum conectivo de entrada como possíveis valores, ou constantes. 6. Se dois conceitos tiverem o mesmo nome diferenciá-los com índice. 7. Redefinir conceitos que possuírem verbos de entrada de ligação e de saída de ação como condição. 8. Conceitos filhos de conceitos condição, serão referenciados ao pai da condição. 9. Atribuir cada conceito que possuir conceitos filhos do tipo condição como classe. 10. Repetir passo 5 para conceitos definidos como atributos de um conceito que não está definido como classe, redefinindo o pai, como o sendo o pai do pai (subir um nível de hierarquia no mapa) Aplicação da Metodologia no Estudo de Caso: Aplicando os passos de 1 a 8 chegaremos a seguinte tabela: Conceito Conceitos Pai Tipos de Verbo Tipos de Verbo Definição (entrada) (saída) Partida de Xadrez Nulo Não importa Não importa Entidade Australiana Usuário do Sistema Nulo Não importa Não importa Entidade Movimentar peça Ativo Ação Ação Método de Turno de Jogo Conversar Sala de Bate-papo, Ação Nulo Método ativo, inativo Repositório de peças inativas Ação Nulo Atributo de
8 Movimento específico Regras do Jogo de Xadrez Original Mesas de jogo Tipos,movimentar peça Partida de Xadrez Australiana, Movimento específico Partida de Xadrez Australiana, mesa de jogo peças Composição relacional Atributo de tipo. Composição, relacional Nulo Atributo de partida de xadrez australiana. Composição composição Sub-Classe de Partida de Xadrez Australiana. Tipo Peças composição Composição,ligação Sub-Classe de tipo Nome Tipo Composição Nulo Atributo de tipo Peça Mesas de jogo Composição Composição, Sub-classe de ligação, ação mesas Cor Peças Composição Ligação Atributo de peças Jogador Em mesas de jogo Outros Composição Entidade Tempo inicial Relógios, Composição, Nulo Atributo de administrador ação Jogador, Mesa de Jogo Tempo atual Relógios, ativos Composição,ação Nulo Atributo de Mesa de Jogo Sala de Bate-Papo Mesas de jogo Composição Ação Sub-classe de mesas Brancas Cor Ligação Nulo Valor de cor, constante Negras Cor Ligação Nulo Valor de cor, constante Brancas 2 Casas Ligação Nulo Valor de casa, constante Negras 2 Casas Ligação Nulo Valor de casa, constante Tabuleiro Mesas de jogo Composição Ação, composição Sub-Classe de mesas Casas Tabuleiro Composição Ligação Atributo de tabuleiro Ativas Peças Ligação Composição, ação Valor ou constante de Peças; condição Inativas Peças Ligação Composição, ação Valor ou constante de Peças, condição Turno de Jogo Jogador Composição Ligação Sub-Classe de Jogador Ativo Turno de Jogo Ligação Composição, ação Condição Inativo Turno de Jogo Ligação Composição, ação Valor ou constante de Turno de Jogo Mesa de jogo 2 Usuário do Sistema Ligação Relacional Atributo de usuário Relógios Mesa de jogo, Composição Composição, Sub-Classe de jogador Ligação, jogador Apelido Jogador Composição Nulo Atributo de jogador Senha Jogador Composição Nulo Atributo de
9 jogador Pontuação Jogador Composição Nulo Atributo de jogador Ativos Relógios Ligação Ação Condição de Relógio Inativos Relógios Ligação Nulo Valor de Relógio Em nenhuma mesa de Jogador Ligação Ação Condição de jogo Usuário do Sistema Criar mesa Em nenhuma mesa Ação Nulo Método de de jogo Jogador Entrar em mesa Em nenhuma mesa Ação Nulo Método de Conversar Resultados da análise: de jogo Em nenhuma mesa de jogo Jogador Ação nulo Método de Jogador A partir da execução do método foi possível obter o seguinte diagrama de classes. figura 2: Diagrama de classe a partir do CMAP A metodologia CRC/WB+ adotada como modelo de referência, forneceu o seguinte diagrama de classes:
10 figura 3: diagrama de classes obtidas a partir de CRC/WB+ 6-Conclusão: Quando comparado com o diagrama obtido na metodologia CRC/WB+ existem 5 classes em comum que o diagrama obtido através da metodologia é representativo. Além dos cartões CRC de cada classe, também já é possível estabelecer relacionamentos de hierarquia entre as classes, o que constitui uma vantagem em relação ao processo já existente. Para o bom funcionamento da metodologia é importante que o mapa conceitual seja construído de maneira adequada seguindo as recomendações da seção 2. Já existem softwares no mercado, capazes de realizar a criação de mapas conceituais a partir de descrições textuais. Utilizando a metodologia acima, podemos construir um software que realize a conversão dos mapas conceituais para os elementos de perspectiva de software, fechando o ciclo.os mapas conceituais podem ser comunicados com o software via linguagem XML, e o algoritmo que pode ser implementado computacionalmente, utilizando ferramentas relativas e teoria dos grafos. A construção de uma ferramenta CASE baseada na metodologia de análise descrita pode vir a facilitar a tarefa de construir programas OO através de engenharia de software. Essa metodologia proposta é passível de revisão; são necessários alguns estudos adicionais, com outros casos de uso para corroborar o seu funcionamento. Ainda assim, foi alcançado o objetivo de estabelecer uma relação entre os mapas conceituais que representam a perspectiva do cliente e os elementos de perspectiva de software. 7-Agradecimentos: Agradeço aos professores José Maria Parente de Oliveira por me orientar na construção desse artigo. Agradeço também ao professor Clóvis Torres Fernandes por me despertar o interesse pela disciplina de engenharia de software, e ao Inaldo Capistriano Costa, por me fornecer material de apoio. Ao professor Paulo Marcelo Tasinaffo, pela compreensão e, especialmente, ao CNPQ por viabilizar essa pesquisa. 8-Referências: Cockburn, A. (2000). Writing Effective Use Cases. Addison Wesley. Costa, I.C,Oliveira J.M.P, Fernandes C.T (2005), Utilização de Mapa Conceitual na modelagem de um sistema simples (não-publicado). Departamento de Ciências da Computação Instituto Tecnológico de Aeronáutica (ITA) São José dos Campos SP Brasil Fowler, M. (2003). UML Distilled. Addison-Wesley, 3th edition. Moreira, M. A. (1997). Mapas conceituais e aprendizagem significativa. Technical report,
11 Instituto de F ısica - UFRGS. Novak, J. D. (1998). Learning, Creating, and Using Knowledge: Concept Map as Facilitative Tools in Schools and Corporations. Lawrence Erlbaum Associates, Publishers. Sommerville, I. (2005). Engenharia de Software - 6a Edição. Addison Wesley.
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 maisTRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES
TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado
Leia maisALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA
ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do
Leia maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisPersistência e Banco de Dados em Jogos Digitais
Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem
Leia maisConcepção e Elaboração
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo
Leia maisModelagemde Software Orientadaa Objetos com UML
Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para
Leia maisIntrodução a UML. Hélder Antero Amaral Nunes haanunes@gmail.com
Introdução a UML Hélder Antero Amaral Nunes haanunes@gmail.com Introdução a UML UML (Unified Modeling Language Linguagem de Modelagem Unificada) é uma linguagem-padrão para a elaboração da estrutura de
Leia maisINSTITUTO TECNOLÓGICO DE AERONÁUTICA Divisão de Ciência da Computação. CES 31 - Engenharia de Software Prof. Dr. Clóvis Torres Fernandes FEI DEZENHO
INSTITUTO TECNOLÓGICO DE AERONÁUTICA Divisão de Ciência da Computação CES 31 - Engenharia de Software Prof. Dr. Clóvis Torres Fernandes FEI DEZENHO Dafne Guisard Guilherme Salerno Juliana Gregory Cavalcante
Leia maisFATEC Cruzeiro José da Silva. Ferramenta CRM como estratégia de negócios
FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Cruzeiro SP 2008 FATEC Cruzeiro José da Silva Ferramenta CRM como estratégia de negócios Projeto de trabalho de formatura como requisito
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação
SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula
Leia maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia maisAnálise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)
Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem
Leia maisConceitos de Banco de Dados
Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir
Leia maisUML: Diagrama de Casos de Uso, Diagrama de Classes
UML: Diagrama de Casos de Uso, Diagrama de Classes Diagrama de Casos de Uso O modelo de casos de uso visa responder a pergunta: Que usos (funcionalidades) o sistema terá? ou Para que aplicações o sistema
Leia maisOrientação a Objetos
1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou
Leia maisEngenharia 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 maisLINGUAGEM DE BANCO DE DADOS
LINGUAGEM DE BANCO DE DADOS Gabriela Trevisan Bacharel em Sistemas de Informação Universidade Federal do Rio Grande Pós-Graduanda Formação Pedagógica de Professores (FAQI) Conceito de BD Um banco de dados
Leia maisCasos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1
Casos de Uso Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 O que é? Uma técnica para capturar requisitos funcionais Descreve o sistema sob a perspectiva
Leia mais3.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 maisA Linguagem de Modelagem Unificada (UML)
Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)
Leia maisRequisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa
Leia maisAnálise e Projeto Orientado a Objetos. Modelagem de Domínio
+ Análise e Projeto Orientado a Objetos Modelagem de Domínio Introdução 2 n A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação
Leia maisGerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto
Gerenciamento de Projetos Modulo II Ciclo de Vida e Organização do Projeto Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Organização do Projeto Os projetos e o gerenciamento
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia mais)HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR
6LPXODomR GH6LVWHPDV )HUUDPHQWDV &RPSXWDFLRQDLV SDUD 6LPXODomR #5,6. Simulador voltado para análise de risco financeiro 3RQWRV IRUWHV Fácil de usar. Funciona integrado a ferramentas já bastante conhecidas,
Leia maisSistemas de Informação I
+ Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas
Leia maisDiagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.
1 Diagrama de Classes Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes. Um dos objetivos do diagrama de classes é definir a base para
Leia maisATRIBUTOS PRIVADOS 6. ENCAPSULAMENTO MÉTODOS PRIVADOS MÉTODOS PRIVADOS
ATRIBUTOS PRIVADOS Podemos usar o modificador private, para tornar um atributo privado, obtendo um controle centralizado Definimos métodos para implementar todas as lógicas que utilizam ou modificam o
Leia maisHistórico da Revisão. Data Versão Descrição Autor
Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não
Leia maisProgramação Orientada a Objetos. Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br http://www.diemesleno.com.br
Programação Orientada a Objetos Prof. Diemesleno Souza Carvalho diemesleno@iftm.edu.br http://www.diemesleno.com.br Programação Orientada a Objetos Na aula passada, vimos: Encapsulamento Programação Orientada
Leia maisBanco de Dados Aula 1 Introdução a Banco de Dados Introdução Sistema Gerenciador de Banco de Dados
Banco de Dados Aula 1 Introdução a Banco de Dados Introdução Um Sistema Gerenciador de Banco de Dados (SGBD) é constituído por um conjunto de dados associados a um conjunto de programas para acesso a esses
Leia maisPLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES?
PLANEJAMENTO OPERACIONAL - MARKETING E PRODUÇÃO MÓDULO 3 O QUE É PLANEJAMENTO DE VENDAS E OPERAÇÕES? Índice 1. O que é planejamento de...3 1.1. Resultados do planejamento de vendas e operações (PVO)...
Leia maisO modelo Entidade-Relacionamento. Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento
O modelo Entidade-Relacionamento Agenda: -Modelagem de dados utilizando O Modelo Entidade-Relacionamento 1 Antes de começarmos: A modelagem conceitual é uma fase muito importante no plamejamento de um
Leia maisUML - 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 maisMRP II. Planejamento e Controle da Produção 3 professor Muris Lage Junior
MRP II Introdução A lógica de cálculo das necessidades é conhecida há muito tempo Porém só pode ser utilizada na prática em situações mais complexas a partir dos anos 60 A partir de meados da década de
Leia maisUm Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena
Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE
Leia maisEngenharia de Software
Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São
Leia maisAqui você também vai encontrar o botão ""Autocompletar"", que ajuda na criação do alinhamento, caso você não consiga se decidir.
1. ATIVAR CARTA Nesta seção, localizada dentro do ""shopping center"", você precisa inserir o código que aparece no verso da sua carta real para adicioná-la à sua coleção virtual. Às vezes, você pode se
Leia maisResolução da lista de exercícios de casos de uso
Resolução da lista de exercícios de casos de uso 1. Explique quando são criados e utilizados os diagramas de casos de uso no processo de desenvolvimento incremental e iterativo. Na fase de concepção se
Leia maisAutoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Introdução Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia maisWilson Moraes Góes. Novatec
Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,
Leia maisPROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br
PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes
Leia maisModelagem de Casos de Uso (Parte 1)
Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de
Leia maisCasos de uso Objetivo:
Casos de uso Objetivo: Auxiliar a comunicação entre os analistas e o cliente. Descreve um cenário que mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve ver no diagrama de
Leia maisProgramação Orientada a Objetos Herança Técnico em Informática. Prof. Marcos André Pisching, M.Sc.
Herança Técnico em Informática, M.Sc. Herança 2 Herança Reutilização de código Exemplo Banco: Um banco oferece diversos serviços que podem ser contratados individualmente pelos clientes. Quando um serviço
Leia maisPLANOS DE CONTINGÊNCIAS
PLANOS DE CONTINGÊNCIAS ARAÚJO GOMES Capitão SC PMSC ARAÚJO GOMES defesacivilgomes@yahoo.com.br PLANO DE CONTINGÊNCIA O planejamento para emergências é complexo por suas características intrínsecas. Como
Leia maisGuia de Especificação de Caso de Uso Metodologia CELEPAR
Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007
Leia maisImplantação. Prof. Eduardo H. S. Oliveira
Visão Geral A implantação de um sistema integrado de gestão envolve uma grande quantidade de tarefas que são realizadas em períodos que variam de alguns meses a alguns anos, e dependem de diversos fatores,
Leia maisFACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>
FACULDADE DE ENGENHARIA DE COMPUTAÇÃO PROJETO FINAL I e II PLANO DE TRABALHO O Trabalho de Conclusão de Curso (TCC) a ser desenvolvido
Leia maisSumário. Uma visão mais clara da UML
Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da
Leia maisIntrodução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3
Introdução ao Aplicativo de Programação LEGO MINDSTORMS Education EV3 A LEGO Education tem o prazer de trazer até você a edição para tablet do Software LEGO MINDSTORMS Education EV3 - um jeito divertido
Leia maisProf. Me. Marcos Echevarria
Prof. Me. Marcos Echevarria Introdução a engenharia de software; Conceito de análise orientada a objetos; UserStories; Requisitos de software; Técnicas de levantamento de requisitos; Modelo de casos de
Leia maisAlgoritmos não se aprendem: Copiando algoritmos Estudando algoritmos Algoritmos só se aprendem: Construindo algoritmos Testando algoritmos
1. INTRODUÇÃO A ALGORITMOS O uso de algoritmos é quase tão antigo quanto a matemática. Com o passar do tempo, entretanto, ele foi bastante esquecido pela matemática. Com o advento das máquinas de calcular
Leia maisEngenharia de Requisitos
Engenharia de Requisitos Conteúdo Definição Questionamentos Típicos Visão Geral Ciclo de Vida dos Requisitos Síntese dos Objetivos Gerência de Mudança Identificação de Requisitos Classificação de Requisitos
Leia maisDesenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto
Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto
Leia maisModelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.
Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever
Leia maisGuia 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 maisUNIVERSIDADE DE SÃO PAULO E S C O L A D E A R T E S, C I Ê N C I A S E H U M A N I D A D E
UNIVERSIDADE DE SÃO PAULO E S C O L A D E A R T E S, C I Ê N C I A S E H U M A N I D A D E Trabalho proposto pela disciplina de Orientado por Professor Dr. Fernando Coelho Mário Januário Filho 5365372
Leia maisAnálise de Sistemas. Visão Geral: Orientação a Objetos. Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br
Análise de Sistemas Visão Geral: Orientação a Objetos Prof. José Honorato Ferreira Nunes Prof. José Honorato Ferreira Nunes honorato.nunes@bonfim.ifbaiano.edu.br Resumo: VISÃO GERAL: Modelagem de sistemas
Leia maisEngenharia de Requisitos
Engenharia de Requisitos Introdução a Engenharia de Requisitos Professor: Ricardo Argenton Ramos Aula 08 Slide 1 Objetivos Introduzir a noção de requisitos do sistema e o processo da engenharia de requisitos.
Leia maisIMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR
IMPLEMENTAÇÃO DAS CAMADAS Inference Machine e Message Service Element PARA UM SERVIDOR DE SISTEMA DE GERENCIAMENTO DE Workflow HOSPITALAR Jeferson J. S. Boesing 1 ; Manassés Ribeiro 2 1.Aluno do Curso
Leia maisManual SAGe Versão 1.2 (a partir da versão 12.08.01)
Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação
Leia maisModelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza
Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira
Leia maisDescrição e regras e dinâmica do jogo Unidos para produzir um lugar saudável - PDTSP TEIAS
Descrição e regras e dinâmica do jogo Unidos para produzir um lugar saudável - PDTSP TEIAS Peças do jogo O jogo Unidos para produzir um lugar saudável PDTSP TEIAS Escola Manguinhos Versão inicial é composto
Leia maisUML Aspectos de projetos em Diagramas de classes
UML Aspectos de projetos em Diagramas de classes Após ser definido o contexto da aplicação a ser gerada. Devemos pensar em detalhar o Diagrama de Classes com informações visando uma implementação Orientada
Leia maisAnálise e Projeto Orientados por Objetos
Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender
Leia maisPROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às
Leia maisPós-Graduação em Gerenciamento de Projetos práticas do PMI
Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL
Leia maisUnisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER
Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem
Leia maisEngenharia de Software
Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo
Leia mais5 Experiência de implantação do software de roteirização em diferentes mercados
5 Experiência de implantação do software de roteirização em diferentes mercados 5.1 Introdução Após apresentação feita sobre os processos para implantação de um software de roteirização de veículos da
Leia maisBase de Dados para Administrações de Condomínios
Base de Dados para Administrações de Condomínios José Pedro Gaiolas de Sousa Pinto: ei03069@fe.up.pt Marco António Sousa Nunes Fernandes Silva: ei03121@fe.up.pt Pedro Miguel Rosário Alves: alves.pedro@fe.up.pt
Leia maisFeature-Driven Development
FDD Feature-Driven Development Descrição dos Processos Requisitos Concepção e Planejamento Mais forma que conteúdo Desenvolver um Modelo Abrangente Construir a Lista de Features Planejar por
Leia maisSETIS- III Seminário de Tecnologia Inovação e Sustentabilidade 4 e 5 de novembro de 2014.
A importância da comunicação no gerenciamento de projetos de softwares: reflexões teóricas Lucas Krüger lucas_kruger-@hotmail.com Resumo: Esse artigo objetiva estudar a comunicação entre cliente e desenvolvedor
Leia maisDESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES
DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.
Leia maisAUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0
AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento
Leia maisCapítulo 6. Criando um Diagrama de Caso de Uso Inicial
Capítulo 6 Criando um Diagrama de Caso de Uso Inicial Mapa do Processo Por que Necessitamos de Um Diagrama de Casos de Uso? Eis algumas razões da necessidade de um Diagrama de Casos de Uso: O SRS é preenchido
Leia maisESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE
ESTENDENDO A UML PARA REPRESENTAR RESTRIÇÕES DE INTEGRIDADE Fabiana Gomes Marinho Faculdade Lourenço Filho Resumo: Na UML, a modelagem conceitual dos dados é descrita pelo diagrama de classes, que através
Leia maisProf. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.
Visão Geral do Sistema Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. A fase de concepção do UP consiste
Leia maisEspecificação do 3º Trabalho
Especificação do 3º Trabalho I. Introdução O objetivo deste trabalho é abordar a prática da programação orientada a objetos usando a linguagem Java envolvendo os conceitos de classe, objeto, associação,
Leia maisRequisitos de Software. Teresa Maciel DEINFO/UFRPE
Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito
Leia maisProf. Marcelo Henrique dos Santos
ORIENTAÇÃO A OBJETOS COM PROTOTIPAÇÃO CAPÍTULO 02 CONCEITOS FUNDAMENTAIS OBJETIVOS Definiremos alguns conceitos fundamentais de forma a não deixar dúvidas básicas ou interpretações que nos coloquem em
Leia maisModelo Entidade-Relacionamento
Modelo Entidade-Relacionamento Banco de Dados I Fases do Projeto jt de BD Enunciado de requisitos entrevista com o usuário do banco de dados para entender e documentar seus requerimentos de dados. Projeto
Leia mais04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.
MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais
Leia maisAjuda ao SciEn-Produção 1. 1. O Artigo Científico da Pesquisa Experimental
Ajuda ao SciEn-Produção 1 Este texto de ajuda contém três partes: a parte 1 indica em linhas gerais o que deve ser esclarecido em cada uma das seções da estrutura de um artigo cientifico relatando uma
Leia maisUniversidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação
Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto
Leia maisJOGOS ELETRÔNICOS CONTRIBUINDO NO ENSINO APRENDIZAGEM DE CONCEITOS MATEMÁTICOS NAS SÉRIES INICIAIS
JOGOS ELETRÔNICOS CONTRIBUINDO NO ENSINO APRENDIZAGEM DE CONCEITOS MATEMÁTICOS NAS SÉRIES INICIAIS Educação Matemática na Educação Infantil e nos Anos Iniciais do Ensino Fundamental (EMEIAIEF) GT 09 RESUMO
Leia maisProcesso de Desenvolvimento Unificado
Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas
Leia maisAula 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 maisRequisitos de Software
Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,
Leia maisPEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0
PEN - Processo de Entendimento das Necessidades de Negócio Versão 1.4.0 Banco Central do Brasil, 2015 Página 1 de 14 Índice 1. FLUXO DO PEN - PROCESSO DE ENTENDIMENTO DAS NECESSIDADES DE NEGÓCIO... 3 2.
Leia maisATIVIDADES PRÁTICAS SUPERVISIONADAS
ATIVIDADES PRÁTICAS SUPERVISIONADAS Tecnologia em Análise e Desenvolvimento de Sistemas 3ª Série Fundamentos de Análise Orientada a Objetos A atividade prática supervisionada (ATPS) é um método de ensinoaprendizagem
Leia maisGereComSaber. 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 maisATIVIDADES DE LINHA E DE ASSESSORIA
1 ATIVIDADES DE LINHA E DE ASSESSORIA SUMÁRIO Introdução... 01 1. Diferenciação das Atividades de Linha e Assessoria... 02 2. Autoridade de Linha... 03 3. Autoridade de Assessoria... 04 4. A Atuação da
Leia maisRequisitos de Software
Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais
Leia mais