Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case

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

Download "Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case"

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) 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.

Concepção e Elaboração

Concepçã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 mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

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

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 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 mais

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2

Introdução! 1. Modelos de Domínio! 1. Identificação de classes conceituais! 2. Estratégia para identificar classes conceituais! 2 Modelo de domínio Introdução! 1 Modelos de Domínio! 1 Identificação de classes conceituais! 2 Estratégia para identificar classes conceituais! 2 Passos para a elaboração do modelo de domínio! 2 Passo 1

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Requisitos de Software

Requisitos 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

Modelagem 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 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 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

USO DE MAPAS CONCEITUAIS NA AUTORIA DE CURSOS A DISTÂNCIA

USO DE MAPAS CONCEITUAIS NA AUTORIA DE CURSOS A DISTÂNCIA USO DE MAPAS CONCEITUAIS NA AUTORIA DE CURSOS A DISTÂNCIA Anderson Ricardo Yanzer Cabral Resumo Em instituições que trabalham com o desenvolvimento de cursos e treinamentos a distância um dos grandes desafios

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

TRABALHO 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 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 mais

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

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 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 mais

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br)

Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Engenharia de Softwares e Sistema IF682 (2012.1) Bruno Medeiros(bmo@cin.ufpe.br) Algumas definições Engenharia de Software conjunto de tecnologias e práticas usadas para construir software de qualidade

Leia mais

Modelagem de Casos de Uso (Parte 1)

Modelagem 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 mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

UNIP Ciência da Computação AES Análise Essencial de Sistemas

UNIP Ciência da Computação AES Análise Essencial de Sistemas 1 Análise Essencial UNIP Ciência da Computação A análise essencial pode ser considerada um refinamento da análise estruturada. O problema existente (ou situação que requer a informatização) é estudado,

Leia mais

Casos 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 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 mais

Análise Orientada a Objeto

Análise Orientada a Objeto Análise Orientada a Objeto Análise Orientada a Objeto ANÁLISE ORIENTADA A OBJETO É interessante observar como a análise orientada a objeto utiliza conceitos que aprendemos há muito tempo: objetos, atributos,

Leia mais

Diagrama de Caso de Uso e Diagrama de Sequência

Diagrama de Caso de Uso e Diagrama de Sequência Diagrama de Caso de Uso e Diagrama de Sequência Milena Alexandre dos Santos Baesso (Mestranda em Engenharia Elétrica) Agenda Ciclo de Vida de um Sistema A Fase de Análise Análise Orientada à Objetos Diagramas

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistê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 mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET

MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET MedEl: Uma solução de E-Learning utilizando tecnologia Microsoft ASP.NET Átila Correia Cunha 1, 2, Glaucon Henrique Mauricio Maia 1, 2, Waner Ferreira Tavares 1, 2, Jorge Bergson¹, Rui Gomes Patrício 3

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Engenharia de Software

Engenharia 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 mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE 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 mais

BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER )

BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR AULA 02. O Modelo Entidade-Relacionamento ( MER ) AULA 02 BANCO DE DADOS PROFESSOR MAURÍCIO - MAURICIO.MELLO@PUCPR.BR O Modelo Entidade-Relacionamento ( MER ) Fases do Projeto de Bases de Dados (EN94)- O Modelo Entidade- Relacionamento Definição : modelo

Leia mais

Requisitos de Software

Requisitos 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 mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento 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 mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos 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 mais

Engenharia de Requisitos

Engenharia 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 mais

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO 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 mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Elaboração 2 VISÃO GERAL Fase Elaboração. Visão Geral 3

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

Banco de Dados Aula 02. Colégio Estadual Padre Carmelo Perrone Profº: Willian

Banco de Dados Aula 02. Colégio Estadual Padre Carmelo Perrone Profº: Willian Banco de Dados Aula 02 Colégio Estadual Padre Carmelo Perrone Profº: Willian Conceitos básicos Dado: Valor do campo quando é armazenado dento do BD; Tabela Lógica: Representa a estrutura de armazenamento

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados -

Aula 02 Modelagem de Dados. Banco de Dados. Aula 02 Modelagem de Dados. Superior /2011 Redes Computadores - Disciplina: Banco de Dados - Banco de Dados Aula 02 Modelagem de Dados Roteiro Definição Evolução Projeto de BD Abstração Esquema e Instância Definição É uma representação, normalmente gráfica, de estruturas de dados reais. Auxilia

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2010.1/es1

Casos de Uso. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2010.1/es1 Casos de Uso Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2010.1/es1 O que é? Uma técnica para capturar requisitos funcionais Descreve o sistema sob a perspectiva

Leia mais

UML: Diagrama de Casos de Uso, Diagrama de Classes

UML: 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 mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 UML Linguagem Unificada de Modelagem Análise Orientada a Objetos com UML Análise Orientada a Objetos com UML Diagrama de Caso

Leia mais

UML: Casos de Uso. Projeto de Sistemas de Software

UML: Casos de Uso. Projeto de Sistemas de Software UML: Casos de Uso Projeto de Sistemas de Software UML Casos de Uso Introdução Casos de uso Elementos do diagrama de casos de uso Descrição de casos de uso Exemplo: Blog Ferramentas de modelagem Bibliografia

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso

Casos de Uso O que é. Casos de Uso. Objetivos de um Caso de Uso. Atores. Atores e Casos de Uso. Diagramas de Caso de Uso Casos de Uso O que é Casos de Uso Descrições narrativas de processos do domínio da aplicação Documentam a seqüência de eventos de um ator (um agente externo) usando o sistema para completar, do início

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant 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 mais

Análise e Projeto Orientado a Objetos. Modelagem de Domínio

Aná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 mais

LICENCIATURA EM COMPUTAÇÃO

LICENCIATURA EM COMPUTAÇÃO Coordenador: Duração: Carga Horária: LICENCIATURA EM COMPUTAÇÃO Victor Emanuel Corrêa Lima 6 semestres 2800 horas Situação Legal: Reconhecido pela Portaria MEC nº 503 de 15/02/2006 MATRIZ CURRICULAR Primeiro

Leia mais

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos)

Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Sommerville, Ian. Software Engineering. Editora: Addison Wesley. (capítulos sobre Requisitos) Engenharia, Levantamento, Elicitação, Gerenciamento Fernando Pedrosa fpedrosa@gmail.com 1 2 Área da Engenharia

Leia mais

SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM

SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM SISTEMA PARA CONTROLE DE RESERVA DE EQUIPAMENTOS MULTIMEIOS E AMBIENTES DE APRENDIZAGEM Marcelo Karpinski Brambila Acadêmico em Sistemas de Informação Universidade Luterana do Brasil Guaíba mkbrambila@connect-rs.com.br

Leia mais

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML.

Palavras-Chaves: Arquitetura, Modelagem Orientada a Objetos, UML. MODELAGEM ORIENTADA A OBJETOS APLICADA À ANÁLISE E AO PROJETO DE SISTEMA DE VENDAS ALTEMIR FERNANDES DE ARAÚJO Discente da AEMS Faculdades Integradas de Três Lagoas ANDRE LUIZ DA CUNHA DIAS Discente da

Leia mais

Diagrama de Classes. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1

Diagrama de Classes. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1 Diagrama de Classes Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 O que é? Diagrama mais utilizado da UML Representa os tipos (classes) de objetos de um

Leia mais

A Linguagem de Modelagem Unificada (UML)

A 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 mais

Programação Orientada a Objetos Herança Técnico em Informática. Prof. Marcos André Pisching, M.Sc.

Programaçã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 mais

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE

CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE CASE Orientada a Objetos com Múltiplas Visões e Implementação Automática de Sistemas - MVCASE Tathiana da Silva Barrére Antonio Francisco do Prado Vitor César Bonafe E-mail: (tathiana,prado,bonafe)@dc.ufscar.br

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

3 OOHDM e SHDM 3.1. OOHDM 32 3 OOHDM e SHDM Com a disseminação em massa, desde a década de 80, de ambientes hipertexto e hipermídia, principalmente a Web, foi identificada a necessidade de elaborar métodos que estruturassem de

Leia mais

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida

Para cada fase consideramos. Tempo para um projeto típico Tempo para um projeto Complexo. Arquitetura do Processo Unificado. A meta a ser atingida Arquitetura do Processo Unificado Tempo para um projeto típico Tempo para um projeto Complexo O tempo gasto nas fases iniciais aumentam Para cada fase consideramos A meta a ser atingida Workflows a executar

Leia mais

Modelo conceitual Aula 08

Modelo conceitual Aula 08 Universidade Federal de Mato Grosso do Sul Sistemas de Informação - CPCX Modelo conceitual Aula 08 Prof. Fernando Maia da Mota Slides gentilmente cedidos por Profa. Dra. Maria Istela Cagnin Machado UFMS/FACOM

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde 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 mais

Construindo disciplinas de Gestão de Pessoas com Mapas Conceituais

Construindo disciplinas de Gestão de Pessoas com Mapas Conceituais Construindo disciplinas de Gestão de Pessoas com Mapas Conceituais Dra. Sonia Mara Thater Romero 1 Ms. Sergio da Costa Nunes 2 1 soniaromero@pop.com.br 2 sergiocnunes@pop.com.br 1 Doutora em Psicologia,

Leia mais

CAPÍTULO 1 INTRODUÇÃO

CAPÍTULO 1 INTRODUÇÃO CAPÍTULO 1 INTRODUÇÃO A atuação do homem no meio ambiente, ao longo da história, fornece provas de suas ações em nome do progresso. Esta evolução tem seu lado positivo, pois abre novos horizontes, novas

Leia mais

Diagrama de Classes. Um diagrama de classes descreve a visão estática do sistema em termos de classes e relacionamentos entre as classes.

Diagrama 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 mais

Análise e Projeto Orientados a Objetos Aula IX Modelo Conceitual do Sistema (Modelo de Domínio) Prof.: Bruno E. G. Gomes IFRN

Análise e Projeto Orientados a Objetos Aula IX Modelo Conceitual do Sistema (Modelo de Domínio) Prof.: Bruno E. G. Gomes IFRN Análise e Projeto Orientados a Objetos Aula IX Modelo Conceitual do Sistema (Modelo de Domínio) Prof.: Bruno E. G. Gomes IFRN 1 Introdução Análise de domínio Descoberta das informações que são gerenciadas

Leia mais

Engenharia de Software. Análise Essencial

Engenharia de Software. Análise Essencial Engenharia de Software Análise Essencial 1 Evolução dos métodos de análise de sistemas Métodos Análise Tradicional Análise Estruturada Abordagens Funcional Funcional Dados Ferramentas Textos fluxuogramas

Leia mais

UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas

UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas UNIVERSIDADE DE MOGI DAS CRUZES Centro de Ciências Exatas e Tecnológicas Sistemas de Informação e Tecnologia em 3º Semestre Análise Orientada aos Objetos Modelagem de Casos de Uso Objetivo: Apresentar

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Banco de Dados I Ementa:

Banco de Dados I Ementa: Banco de Dados I Ementa: Banco de Dados Sistema Gerenciador de Banco de Dados Usuários de um Banco de Dados Etapas de Modelagem, Projeto e Implementação de BD O Administrador de Dados e o Administrador

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

PROGRAMAÇÃ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 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 mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos 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 mais

Introduçã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 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 mais

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída

Testes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída DCC / ICEx / UFMG Testes de Software Testes de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Teste de software buscam por erros ou anomalias em requisitos funcionais e não funcionais Classificação

Leia mais

Engenharia de Software

Engenharia de Software Prof. M.Sc. Ronaldo C. de Oliveira ronaldooliveira@facom.ufu.br FACOM - 2011 Análise e Projeto Orientados a Objetos Análise e Projeto Orientados a Objetos O que é Análise e Projeto? Análise o quê Investigação

Leia mais

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5.

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. 1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. Fases do Desenvolvimento de um Sistema em UML 1. Análise

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Projeto de Sistemas I

Projeto 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 mais

3. PARADIGMA ORIENTADO A OBJETOS

3. PARADIGMA ORIENTADO A OBJETOS Paradigmas de Linguagens I 1 3. PARADIGMA ORIENTADO A OBJETOS Este paradigma é o que mais reflete os problemas atuais. Linguagens orientada a objetos (OO) são projetadas para implementar diretamente a

Leia mais

guia prático 2a Edição Gilleanes T.A. Guedes Novatec

guia prático 2a Edição Gilleanes T.A. Guedes Novatec guia prático 2a Edição Gilleanes T.A. Guedes Novatec Copyright 2007, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Programa do Módulo 2. Fundações do Modelo Objeto

Programa do Módulo 2. Fundações do Modelo Objeto 2.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) Processo Unificado (RUP) Fundações do Modelo Objeto 2.2 Programação Orientada a Objetos: é um método de

Leia mais

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem

Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Ontologia Aplicada ao Desenvolvimento de Sistemas de Informação sob o Paradigma da Computação em Nuvem Luiz Cláudio Hogrefe Orientador: Prof. Roberto Heinzle, Doutor Roteiro Introdução Fundamentação teórica

Leia mais

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos

Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Especificação de Sistemas de Tempo-Real utilizando Orientação a Objetos Marco Aurélio Wehrmeister mawehrmeister@inf.ufrgs.br Roteiro Introdução Orientação a Objetos UML Real-Time UML Estudo de Caso: Automação

Leia mais

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades

Leia mais

Engenharia de Software I: Análise e Projeto de Software Usando UML

Engenharia de Software I: Análise e Projeto de Software Usando UML Engenharia de Software I: Análise e Projeto de Software Usando UML Capítulo 1 Processo de Desenvolvimento de Software Metodologia de Desenvolvimento de Software Uma metodologia é um conjunto de métodos,

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

O processo unificado integrado ao desenvolvimento Web

O processo unificado integrado ao desenvolvimento Web O processo unificado integrado ao desenvolvimento Web Rodrigo S. Prudente de Aquino rodrigo@wpage.com.br É bacharel em Ciência da Computação pela PUC-SP e MBA em Engenharia de Software pela USP. Foi analista

Leia mais

Palavras-Chaves: engenharia de requisitos, modelagem, UML.

Palavras-Chaves: engenharia de requisitos, modelagem, UML. APLICAÇÃO DA ENGENHARIA DE REQUISITOS PARA COMPREENSÃO DE DOMÍNIO DO PROBLEMA PARA SISTEMA DE CONTROLE COMERCIAL LEONARDO DE PAULA SANCHES Discente da AEMS Faculdades Integradas de Três Lagoas RENAN HENRIQUE

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II

PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II UNIOESTE - Universidade Estadual do Oeste do Paraná CCET - Centro de Ciências Exatas e Tecnológicas Colegiado de Informática Curso de Bacharelado em Informática PROJETO DA DISCIPLINA PES II Processo de

Leia mais

Análise Orientada a Objetos

Análise Orientada a Objetos Análise Orientada a Objetos Breve Histórico: Fim da década de 80: amadurecimento da Orientação a Objeto Década de 1990: diversas proposições a partir de diversos autores, como Booch, Rumbaugh e Jacobson.

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Roteiro Conceitos Engenharia de requisitos Artigo Definições de requisitos Requisitos de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas

Leia mais

Engenharia de Requisitos

Engenharia 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 mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteú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

Documento de Projeto de Sistema

Documento de Projeto de Sistema Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda,

Leia mais

Métodos de Construção de Software: Análise Estruturada. Graduação em Informática 2008 Profa. Itana Gimenes

Métodos de Construção de Software: Análise Estruturada. Graduação em Informática 2008 Profa. Itana Gimenes Métodos de Construção de Software: Análise Estruturada Graduação em Informática 2008 Profa. Itana Gimenes Análise Estruturada Paradigma estruturado Sistemas são vistos como processos que transformam dados.

Leia mais

Analise Estruturada. Diagrama de Fluxo de Dados. Tecnologia em Processamento de Dados Analise de Sistemas

Analise Estruturada. Diagrama de Fluxo de Dados. Tecnologia em Processamento de Dados Analise de Sistemas Analise Estruturada Diagrama de Fluxo de Dados Tecnologia em Processamento de Dados Analise de Sistemas 2 Índice: 1. Introdução, pagina 4 2. Uma Ferramenta Eficaz, pagina 5 3. Analise Estruturada, Benefícios

Leia mais