Critérios de Testabilidade para Avaliação do Modelo de Projeto de Software Orientado a Aspectos
|
|
- Luiz Gustavo Canejo Costa
- 6 Há anos
- Visualizações:
Transcrição
1 Critérios de Testabilidade para Avaliação do Modelo de Projeto de Software Orientado a Aspectos Paulo Afonso Parreira Júnior 1, Heitor Augustus Xavier Costa 2, Antônio Maria Pereira de Resende 3, Fábio Fagundes Silveira 4 1, 2, 3 PqES Grupo de Pesquisa em Engenharia de Software Departamento de Ciência da Computação (DCC) Universidade Federal de Lavras (UFLA) Caixa Postal 3037 CEP Lavras MG Brasil 4 Departamento de Ciência e Tecnologia (DCT) Universidade Federal de São Paulo (UNIFESP) CEP São José dos Campos SP Brasil 1 paulojr@comp.ufla.br, 2 heitor@ufla.br, 3 tonio@dcc.ufla.br, 4 fsilveira@unifesp.br Abstract. Software testing aims to ensure the best possible software quality. Despite being impossible to prove that software has no faults, testing supplies evidence of the conformity with the specified functionality. However, testing activities need to have their planning started at the beginning of the development cycle, contributing to avoid faults and their propagation throughout the development phases. This paper proposes an evaluation of the aspect-oriented software Design Model, considering testability characteristics. To achieve it, we have defined a set of testability criteria to be used in such an evaluation. These criteria were used in an application in order to evaluate their effectiveness. Keywords: Software Quality, Software Test, Aspect-Oriented Resumo. A atividade de teste de software é realizada visando assegurar a maior qualidade possível do software. Apesar de ser impossível provar que um software é livre de defeitos, a aplicação de testes fornece evidências da conformidade com a funcionalidade especificada. Entretanto, sabe-se que as atividades relacionadas com os testes precisam ter o seu planejamento iniciado logo no princípio do ciclo de desenvolvimento, contribuindo para evitar defeitos e sua propagação nas demais fases do desenvolvimento. Desta forma, este trabalho propõe a avaliação do Modelo de Projeto de software orientado a aspecto, considerando as características de testabilidade. Para isso, foi definido um conjunto de critérios de testabilidade para ser usado na avaliação. Estes critérios foram utilizados numa aplicação para verificar a sua usabilidade. Palavras Chave: Qualidade de Software, Teste de Software, Orientação a Aspectos 1. Introdução O processo de verificação e de validação compreende as atividades e as análises que asseguram que o software atende às especificações e às necessidades para as quais ele foi desenvolvido [Sommerville 2001]. A atividade de teste é uma das técnicas mais 50
2 utilizadas de verificação e de validação, constituindo-se num dos elementos para fornecer evidências sobre a confiabilidade do software em complemento a outras atividades, como por exemplo, o uso de revisões e de técnicas formais de especificação e de validação [Maldonado 1991]. Segundo Pressman (2006), a atividade de teste é um elemento crítico da garantia de qualidade de software e pode assumir até 50% do esforço despendido no desenvolvimento de software. Em decorrência da complexidade das tarefas de criação e de implementação de software não-triviais, novas tecnologias são estudadas e aplicadas ao seu processo de desenvolvimento para facilitar essas tarefas. Isto é realizado desde os primórdios da programação, podendo-se observar a evolução destas tecnologias partindo-se da programação utilizando linguagens em nível de máquina e passando pelos paradigmas Procedural, Orientado a Objetos (OO) e Orientado a Aspectos (OA). O paradigma OA estende o paradigma OO com o intuito de tratar o entrelaçamento e o espalhamento de certos requisitos (interesses transversais), visando, entre outras características de qualidade, a manutenibilidade e a reusabilidade [Elrad et al. 2001]. Existem algumas referências na literatura [Zhao and Rinard 2003], [Zhao 2003], [Zhao 2002] que discorrem sobre o fato da adoção do Desenvolvimento de Software Orientado a Aspectos (DSOA) eventualmente propiciar software com maior qualidade, porém, a OA não provê corretude por si só [Silveira 2007]. Conforme descrito por Zhao (2003), ainda que a programação OA possa conduzir a uma melhor arquitetura e uma linguagem OA possa conduzir a um estilo de codificação mais disciplinado, ambas não possuem imunidade de erros de programadores nem de falta de entendimento de especificações. Sendo assim, a atividade de teste também é essencial para o DSOA. Um fator motivador deste trabalho é a importância, destacada por vários autores [Binder 2000], [Colanzi 1999], [McGregor and Sykes 2001], de realizar as atividades de teste desde o início do ciclo de desenvolvimento de software. Outro fator é o crescente uso de OA no desenvolvimento de software. Isso pode ser verificado com eventos de relevância que têm ocorrido, como por exemplo, o Latin-American Workshop on Aspect-Oriented Software Development e a International Conference on Aspect- Oriented Software Development. Desta forma, este trabalho baseia-se na incorporação de características de testabilidade na fase de projeto, realizando avaliação destas características no Modelo 1 de Projeto por meio de critérios de testabilidade a serem seguidos. O Modelo de Implementação, embora apresente características importantes às atividades relacionadas com o teste, não é considerado neste trabalho. Esta decisão visa a incentivar a prática de construção de software com característica de testabilidade desde o início do desenvolvimento. Com isto, pode-se obter os seguintes benefícios: i) redução de esforços para a elaboração dos testes, visto que as contribuições para a sua elaboração são apontadas nos artefatos gerados no Modelo de Projeto; e ii) redução dos gastos associados à correção de defeitos identificados, pois diminui a possibilidade de propagação dos defeitos entre as diferentes fases do desenvolvimento. 1 Modelo do Software é uma representação do software em vários níveis de abstração, dependendo da fase do processo de desenvolvimento (análise/projeto/implementação/teste/manutenção). Neste caso, o Modelo de Projeto está relacionado ao conjunto de artefatos gerados durante a fase de projeto, enquanto o Modelo de Implementação está relacionado à codificação dos sistemas de informação em desenvolvimento [Filman et al. 2005]. 51
3 O objetivo deste trabalho é apresentar um conjunto de critérios de testabilidade para a avaliação do Modelo de Projeto de software OA, elaborada a partir de características de testabilidade identificadas à luz da norma ISO/IEC 9126 (Tecnologia da Informação Características e Métricas de Qualidade de Software) [ISO Std ], [ISO Std ]. O artigo está organizado da seguinte forma: a Seção 2 discorre sobre a fundamentação teórica e lista alguns trabalhos relacionados; a Seção 3 apresenta os critérios de testabilidade; a Seção 4 ilustra o uso dos critérios de testabilidade propostos; por fim, a Seção 5 apresenta algumas conclusões. 2. Fundamentação Teórica A norma ISO/IEC 9126 [ISO Std ], [ISO Std ] define testabilidade como o conjunto de atributos do software que evidenciam o esforço necessário para validá-lo após modificá-lo. Segundo Tannouri (2006), a característica de testabilidade pode ser incorporada nos vários estágios do desenvolvimento do software: i) especificação; ii) projeto; iii) codificação; e iv) testes. Dentre as tecnologias para DSOA, utiliza-se a asideml para a representação do Modelo de Projeto. asideml foi proposta por Chavez (2004) e consiste em uma linguagem de modelagem desenvolvida para especificar e comunicar projetos OA. Para isto, a asideml define novos e enriquece alguns diagramas da Unified Modeling Language (UML) para apresentar os elementos entrecortantes (crosscutting 2 ) e os seus relacionamentos com os elementos base 3 [Chavez 2004]: Diagrama de Aspectos. Este diagrama exibe a descrição de um aspecto que incorpora as interfaces transversais 4, as características locais (atributos e métodos) e os relacionamentos de herança. Cada característica transversal comportamental 5 pode ser visualizada em um Diagrama de Colaboração Aspectual 6 ; Diagrama de Classes Estendido. Este diagrama apóia representação gráfica da visão de projeto estático do software. Além disso, ele permite visualizar cada aspecto em detalhe e separadamente no Diagrama de Aspecto correspondente e representa uma coleção de elementos de modelagem estrutural, como aspectos, classes, interfaces e seus relacionamentos, conectados entre si como um grafo; Diagrama de Seqüência Aspectual. Este diagrama fornece representação gráfica de um conjunto de mensagens organizadas em seqüência temporal (algumas mensagens denotam invocações a operações de aspectos) e suporte à visão de interação; Diagrama de Processo de Combinação. Este diagrama fornece representação gráfica para um grupo de elementos combinados (elementos base adornados de forma a enfatizar as melhorias proporcionadas pelos elementos crosscutting). Esses 2 Denota um mecanismo usado para compor aspectos e componentes nos join points designados. 3 A terminologia utilizada neste trabalho está de acordo com o trabalho de Chavez (2004) sobre asideml, não correspondendo necessariamente às traduções realizadas por Garcia et al. (2004). 4 Conjuntos de características transversais com nome associado, que caracterizam o comportamento crosscutting de aspectos. 5 Operações que descrevem melhorias no comportamento de componentes (unidades da decomposição funcional do sistema encapsuladas de forma clara). 6 Descrição da organização geral de objetos e instâncias de aspectos que interagem em um contexto a fim de implementar o comportamento crosscutting de uma característica transversal comportamental. 52
4 elementos podem ser especializados para cada modelo de implementação disponível; Diagrama de Colaboração Aspectual. Este diagrama fornece representação gráfica de uma colaboração aspectual, com suporte a interaction view, que envolve instâncias de aspectos e elementos base. Uma colaboração aspectual possui uma parte estática (descreve os papéis que objetos e instâncias de aspecto exercem) e uma parte dinâmica (mostra os fluxos de mensagens ao longo do tempo para realizar o comportamento crosscutting). A Tabela 1 e a Tabela 2 apresentam breve descrição e respectivas representações gráficas de alguns elementos de modelagem que compõem o Diagrama de Aspectos e o Diagrama de Classe Estendido de asideml utilizados no exemplo de aplicação deste trabalho. Tabela 1 Elementos de Modelagem do Diagrama de Aspectos Elemento Representação Descrição Aspecto Um aspecto é uma descrição de um conjunto de características que alteram a estrutura e o comportamento de classes por meio de crosscutting de forma sistêmica. Interface Transversal e Característica Transversal Características transversais descrevem uma propriedade nomeada (atributo ou operação) definida em um aspecto que pode afetar um ou mais elementos base em locais específicos por meio de crosscutting. Uma interface transversal é o conjunto de características transversais com nome associado, que caracterizam o comportamento crosscutting de aspectos. Embora não haja consenso sobre qual a melhor linguagem de modelagem OA a ser utilizada, a abordagem asideml se apresentou mais adequada, pois ela propõe um modelo de aspectos de alto nível, independente de linguagem, bem como contempla os principais conceitos, propriedades e a arquitetura introduzidos pelo projeto OA. Desta forma, asideml oferece recursos (diagramas e elementos de modelagem) suficientes para o levantamento de informações para os testes. Além disso, uma nova versão da 53
5 asideml está em desenvolvimento, objetivando atualizar e aumentar a sua funcionalidade de maneira a atender à demanda crescente dos seus usuários. Tabela 2 Elementos de Modelagem do Diagrama de Classe Estendido Elemento Representação Descrição Crosscutting Em asideml, o relacionamento de crosscutting classifica um relacionamento entre um aspecto e um elemento base. Ele especifica que o aspecto deve atravessar os limites do elemento base em pontos de combinação bem definidos e modificar, incrementalmente, a base nesses pontos. Precedência Esse relacionamento define que um aspecto (o cliente) precede outro aspecto (o fornecedor). Isso significa que o comportamento do aspecto cliente tem precedência em relação ao comportamento do aspecto fornecedor no tipo de crosscutting que esperam realizar. Durante pesquisas realizadas, notou-se a escassez de trabalhos que tratam diretamente a característica de testabilidade ao longo do processo de DSOA. Contudo, considerando OO, Souza (2003) realizou um trabalho relativo à testabilidade de software OO, utilizando UML e Processo Unificado, com o intuito de fornecer subsídios para a elaboração dos documentos de teste por meio da identificação das características que podem ser inseridas no Modelo de Análise. As características de testabilidade foram definidas através do estudo do conteúdo dos documentos de teste e das informações que podem ser inseridas durante a modelagem. Foram propostos critérios de forma a garantir que as características de testabilidade estejam adequadamente representadas nos modelos, além de procedimentos de verificação dos modelos. Um outro trabalho é o de Freedman (1991), que definiu o conceito de testabilidade de domínio do software mediante a aplicação dos conceitos de observabilidade e controlabilidade. Um domínio é testável (domínio-testável) quando ele é observável e controlável, ou seja, quando ele não apresenta incoerências quanto às suas entradas e saídas. Além disso, o autor define métricas para serem usadas na avaliação do nível de esforço para modificar um programa domínio-testável na manutenção. 3. Critérios de Testabilidade para o Modelo de Projeto O contexto de pesquisa deste trabalho envolve o desenvolvimento de uma abordagem relativa à incorporação da característica de testabilidade ao Modelo de Projeto no DSOA, mediante a elaboração de critérios de testabilidade que guiem a avaliação dos artefatos de software. Assim, busca-se reduzir o esforço de transição dos artefatos entre os diferentes níveis de abstração. 54
6 Estendendo o trabalho de Souza (2003), com o diferencial de tratar a testabilidade no DSOA, este trabalho apresenta um conjunto de critérios de testabilidade para o Modelo de Projeto de software OA, do tipo atende ou não-atende, que visam guiar a avaliação de seus artefatos. Esses critérios, denominados Critérios de Testabilidade para o Modelo de Projeto (Testability Criteria for Design Model TC_DM), foram elaborados baseando-se nas características de testabilidade [ISO Std ], [ISO Std ]. Esta pesquisa encontra-se em nível intermediário e, desta forma, poucos critérios foram definidos até o momento. Por ora, três critérios são apresentados (Figura 1) e seguem a seguinte estrutura: i) critério: identifica o TC_DM com número e descrição; e ii) justificativa: justifica o uso do TC_DM. 4. Exemplo de Aplicação: Sistema do Domínio Bancário A fim de verificar a aplicabilidade dos TC_DMs, decidiu-se utilizá-los para guiar a construção do Modelo de Projeto de um sistema hipotético, denominado SDB (Sistema de Domínio Bancário). Porém, os TC_DMs podem ser utilizados para avaliar um Modelo de Projeto pré-existente, quando necessário. O SDB gerencia operações requeridas por uma agência bancária: efetuar login e logoff, cadastrar e remover clientes, alterar senha, consultar saldo, realizar transferência e efetuar depósito e saque. Os usuários são classificados em administrador e cliente. O SDB possui os seguintes aspectos: APersistencia (persistência), ATransacoes e seu sub-aspecto ATransacoesBancarias (controle de transação), ALogging (histórico de acessos), AIUsuario (declare parents), ATracing (controle de fluxo de execução), APreEPosCondicoes (suporte à verificação de pré e pós-condições), AAutenticacao (autenticação de usuário) e AExcecoes (tratamento de exceções). A seguir, são analisados artefatos do Modelo de Projeto do SDB, exemplificando a aplicação dos três TC_DMs apresentados. TC_DM 1 O relacionamento de precedência entre aspectos permite o rápido reconhecimento da ordem de execução de seus adendos. Justificativa: A ordem em que os adendos de múltiplos aspectos são combinados na aplicação alvo pode afetar o comportamento do sistema, especialmente quando esses aspectos afetam conjuntos de junção coincidentes. Logo, a representação dos relacionamentos de precedência refletirá em implementações mais fáceis de serem testadas, uma vez que a ordem de execução dos adendos é definida a priori. TC_DM 2 Há um conjunto de pontos de junção a serem descartados num relacionamento aspecto-classe fraco. Justificativa: Em um relacionamento crosscuting, caso a restrição seja fraca (pouco restritiva), pontos de junção não requeridos podem ser selecionados, os quais deveriam ser ignorados. Desta forma, uma lista contendo os pontos de junção que deverão ser descartados neste relacionamento facilitará a elaboração dos casos de teste. TC_DM 3 Há um conjunto de pontos de junção a serem considerados num relacionamento aspecto-classe rígido. Justificativa: Em um relacionamento crosscuting, se a restrição for rígida, alguns pontos de junção requeridos podem não ser selecionados. Logo, uma lista contendo os pontos de junção que deverão ser considerados neste relacionamento facilitará a elaboração dos casos de teste. Figura 1 Critérios de Testabilidade para o Modelo de Projeto 55
7 O relacionamento de precedência entre aspectos deve ser respeitado. Como a ordem em que os adendos de múltiplos aspectos são combinados na aplicação alvo pode afetar o comportamento do sistema, especialmente quando esses aspectos interceptam conjuntos de junção coincidentes, a representação dos relacionamentos de precedência entre aspectos é uma boa prática. O TC_DM 1 é verificado no Diagrama de Classes Estendido dos aspectos ALogging e ATracing (Figura 2). A Figura 2 apresenta dois relacionamentos de crosscutting que associam os aspectos ALogging e ATracing à classe Banco. Estes dois aspectos interceptam o método saldo da classe Banco e seu comportamento é alterado nos pontos de combinação definidos pelo pointcut 7 versaldo em ambos os aspectos. O relacionamento precedence é apresentado como uma seta tracejada entre dois elementos do modelo e rotulada com o estereótipo <<precede>>. O aspecto na parte final da seta (o cliente) precede o aspecto na cabeça da seta (o fornecedor). Neste caso, um relacionamento precedence é representado do aspecto ATracing ao aspecto ALogging. Isso significa que o comportamento de tracing ocorre antes do comportamento de logging. Figura 2 - Diagrama de Classes Estendido de ALogging e ATracing O TC_DM 1 pode ser verificado no diagrama da Figura 2, pois existe uma referência explícita ao relacionamento de precedência entre os aspectos envolvidos. A representação dos relacionamentos de precedência refletirá em implementações mais fáceis de serem testadas, uma vez que a ordem de execução dos adendos é definida a priori, contribuindo para aumentar a testabilidade de software OA. 7 Declarações responsáveis por selecionar pontos de execução bem definidos em um programa (join points), ou seja, detectam quais join points o aspecto deve interceptar [Kiczales 2001], [Garcia et al., 2004]. 56
8 O TC_DM 2 e o TC_DM 3 contribuem para tornar a tarefa de elaboração de casos de teste menos árdua, pois exigem que os relacionamentos aspecto-classe a serem executados e/ou descartados sejam explicitados nos artefatos do Modelo de Projeto. A Figura 3 apresenta o diagrama de aspectos de AAutenticacao. Através dela, é possível observar que existem dois pointcuts, _classes e _versaldo, responsáveis por redefinir características comportamentais na classe base. O pointcut _classes representa um relacionamento aspecto-classe fraco e, por isso, pontos de junção não requeridos podem ser afetados por ele. Por outro lado, o pointcut _versaldo representa um relacionamento aspecto-classe forte. Assim, pontos de junção requeridos podem não ser afetados por ele. Para verificar o TC_DM 2, um estereótipo denominado <<ignore>> foi incorporado ao Diagrama de Aspectos de AAutenticacao, juntamente com uma listagem dos pontos de junção que devem ser ignorados para o relacionamento aspecto-classe em questão (pointcut _classes). De modo análogo, para verificar o TC_DM 3, um estereótipo denominado <<include>> foi incorporado ao diagrama juntamente com uma listagem dos pontos de junção que devem ser selecionados para o relacionamento aspecto-classe em questão (pointcut _versaldo). Figura 3 - Diagrama de Aspectos de AAutenticacao 5. Conclusão e Trabalhos Futuros A testabilidade é um importante atributo para a manutenção e garantia de qualidade do software [Chatterjee 2008]. Embora as novas metodologias busquem reduzir a complexidade da sua organização, a atividade de teste continua sendo essencial para o seu desenvolvimento. Além disso, dada a complexidade elevada do software, considerase esta atividade responsável por metade do esforço despendido no seu desenvolvimento. Dessa forma, foi apresentado um conjunto de critérios de testabilidade para guiar a construção do Modelo de Projeto de software OA (TC_DMs). Para verificar a aplicabilidade dos TC_DMs, construiu-se um sistema hipotético de domínio bancário. Visando a atingir a completeza dos critérios, experimentos e estudos de caso, referentes à avaliação/adaptação de Modelos de Projeto OA existentes, devem ser realizados, abrangendo outros domínios do conhecimento, bem como a avaliação da efetividade dos TC_DMs estabelecidos. Desta forma, poderão ser adicionados novos critérios ao conjunto dos TC_DMs e efetuadas adaptações nos TC_DMs definidos. 57
9 foutros desdobramentos deste trabalho incluem: a) a elaboração de diretrizes de testabilidade para o Modelo de Projeto; b) a construção de critérios e diretrizes de testabilidade para os Modelos de Análise e de Implementação; c) a criação e a atualização de uma tabela de rastreabilidade de critérios entre os três modelos; e d) o desenvolvimento de um ambiente para apoiar a abordagem, visando a sua integração ao processo de desenvolvimento. Referências Binder, R. V. (2000) Testing Object-Oriented System Models, Patterns and Tools. Addison-Wesley, 1191p. Chatterjee, I. (2008) Testing Testability. StickyMinds.com. Disponível em: < bjectid=8077&commex=1>. Acessado em: Maio Chavez, C. V. F. G. (2004) Um Enfoque Baseado em Modelos para o Design Orientado a Aspectos. Tese de Doutorado. PUC Rio, Departamento de Informática. 298 f. Colanzi, T. E. (1999) Uma Abordagem Integrada de Desenvolvimento e Teste de Software Baseada na UML. São Carlos, 135p. Dissertação Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo. Elrad, T., Kiczales, G., Aksit, M., Lieberher, K., Ossher, H. (2001) Discussing Aspects of AOP. Communications of the ACM, v. 44, n. 10, p Filman, R. E.; Elrad, T.; Clarke, S.; Aksit, M. Aspect-Oriented Software Development. Addison Wesley Pearson Education, 2005, 755p. Freedman, R. (1991) Testability of Software Components. IEEE Transactions on Software Engineering, 17(6): , June Garcia, A., Chavez, C., Soares, S., Piveta, E., Penteado, R., Camargo, V. V., Fernandes, F. (2004) Relatório do 1º WASP, 10p. ISO Std (1991) Information Technology Software Product Evaluation Quality Characteristics and Guidelines for their use. International Organization for Standardization. ISO Std (2001) Software Enginnering Product Quality Part 1: Quality Model. International Organization for Standardization. Kiczales, G. (2001) Aspect-Oriented Programming with AspectJ (Tutorial), In: OOPSLA 2001, Tampa, Flórida, EUA. Maldonado, J. C. (1991) Critérios Potenciais de Usos: Uma Contribuição ao Teste Estrutural de Software. 169 f. Tese de Doutorado. Unicamp. McGregor, J. D.; Sykes, D. A. (2001) A Pratical Guide to Testing Object-Oriented Software. Addison-Wesley. 393p. Pressman, R. S. (2006) Engenharia de Software, 6ª ed. McGraw-Hill. Silveira, F. F. (2007) METEORA: Um método de Testes Baseado em Estados para Software de Aplicação Orientado a Aspectos. 262f. Tese de Doutorado. Instituto Tecnológico de Aeronáutica (ITA). 58
10 Sommerville, I. (2001) Software Engineering. 6a. Ed. Addison-Wesley. 693p. Souza, R. C. G. (2003) Características de Testabilidade nos Diagramas UML (Unified Modeling Language): Apoio aos Testes de Sistemas de Software Orientados a Objetos. Tese de Doutorado. Escola Politécnica da USP. Tannouri, P. A. (2008) O que é testabilidade. Linha de Código Disponível em: < Acessado em: Maio Zhao, J. (2002) Slicing Aspect-Oriented Software. In: International Workshop on Program Comprehension, Paris. Proceedings. IEEE Computer Society. p Zhao, J. (2003) Data-Flow-Based Unit Testing of Aspect-Oriented Programs. In: Annual International Computer Software and Applications Conference, Proceedings. IEEE Computer Society. p Zhao, J. and Rinard, M. (2003) System Dependence Graph Construction for Aspect- Oriented Programs. Cambridge: MIT, Laboratory for Computer Science. (Technical Report MIT-LCS-TR-891). 59
Critérios de Manutenibilidade para Construção de Produtos de Software Orientados a Aspectos
Critérios de Manutenibilidade para Construção de Produtos de Software Orientados a Aspectos Rodrigo P. dos Santos 1,2, Cláudia M. L. Werner 2, Heitor A. X. Costa 1, Paulo A. P. Júnior 1, André F. Amâncio
Leia maisINF1013 MODELAGEM DE SOFTWARE
INF1013 MODELAGEM DE SOFTWARE Departamento de Informática PUC-Rio Ivan Mathias Filho ivan@inf.puc-rio.br Programa Capítulo 1 O Paradigma Orientado a Objetos A Linguagem UML Descrição da Arquitetura 1 Programa
Leia maisUma Proposta de Critérios de Manutenibilidade para Modelos de Projetos de Software Orientados a Aspectos
Uma Proposta de Critérios de Manutenibilidade para Modelos de Projetos de Software Orientados a Aspectos André Amâncio 1,3, Rodrigo Santos 2, Paulo Parreira Junior 4, Heitor Costa 1, Cláudia Werner 2,
Leia maisNotas de Aula 03: Introdução a Orientação a Objetos e a UML
Notas de Aula 03: Introdução a Orientação a Objetos e a UML Objetivos da aula: Introduzir os conceitos da Orientação à Objetos (O.O) Introduzir os conceitos da UML Relacionar os processos às ferramentas
Leia maisAnálise de Sistemas. Aula 5
Análise de Sistemas Aula 5 Prof. Emerson Klisiewicz CONTEXTUALIZAÇÃO Aula 5 Análise Orientada a Objetos Introdução a UML Histórico e Visão Geral Ferramentas CASE O Sucesso... Clientes satisfeitos Eles
Leia maisALM Aplicações em Linguagem de Montagem. Introdução. A produção de Software é uma atividade build and fix. build. fix
Introdução A produção de Software é uma atividade build and fix. 1 Introdução build 2 Introdução fix 3 1 Introdução 4 P s Só pessoas motivadas e comprometidas com o projeto garantem o respectivo sucesso;
Leia maisUML e seus diagramas
UML e seus diagramas A UML Unified Modeling Language (Linguagem de Modelagem Unificada), como o próprio nome já diz, é uma linguagem para modelagem de objetos do mundo real, usada para especificar, construir,
Leia maisMODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro
MODELAGEM DE SISTEMAS Introdução a Computação e Engenharia de Software Profa. Cynthia Pinheiro Introdução Modelagem de Sistemas: A modelagem de um sistema auxilia o analista a entender a funcionalidade
Leia maisRUP Unified Process. Profª Jocelma Rios
RUP Unified Process Profª Jocelma Rios Nov/2012 O que pretendemos: Reforçar os aspectos que caracterizam o processo iterativo e incremental Identificar como atingir os objetivos dos projetos de software
Leia maisENGENHARIA DE SOFTWARE
ENGENHARIA DE SOFTWARE Teste de Software Verificação e validação Testes de desenvolvimento Testes de release Testes de usuário Desenvolvimento dirigido a testes Kele Teixeira Belloze kelebelloze@gmail.com
Leia maisPrograma Analítico de Disciplina INF323 Engenharia de Software II
0 Programa Analítico de Disciplina Departamento de Informática - Centro de Ciências Exatas e Tecnológicas Número de créditos: Teóricas Práticas Total Duração em semanas: 15 Carga horária semanal 0 Períodos
Leia mais9 Conclusão e trabalhos futuros
255 9 Conclusão e trabalhos futuros O aumento da complexidade das aplicações de software de hoje em dia e o advento de tecnologias inovadoras e recentes fazem com que os sistemas de software incorporem
Leia maisEngenharia de Software I: Introdução. Graduação em Informática 2009 Profa. Itana Gimenes
Engenharia de Software I: Introdução Graduação em Informática 2009 Profa. Itana Gimenes Programa 1. O processo de engenharia de software 2. Engenharia de requisitos 3. Modelagem de sistemas 4. Conceitos
Leia maisISO/IEC Roteiro IEC ISO. Histórico ISO/IEC ISO
Roteiro Processos do Ciclo de Vida de Software Diego Martins dmvb@cin.ufpe.br Histórico Objetivos Organização Processos Fundamentais Processos Organizacionais de Processo IEC ISO International Electrotechnical
Leia maisPOO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos
UEG - Universidade Estadual de Goiás (Câmpus Posse) Disciplina: Análise e Projeto de Sistemas II Turma: 4 Semestre Ano: 2016 Professor: José Ronaldo Leles Júnior O que é? É uma forma de abordar um problema.
Leia mais4 Desenvolvimento de Software Orientado a Aspectos
4 Desenvolvimento de Software Orientado a Aspectos Apesar de ser a tecnologia atualmente dominante no desenvolvimento de software, a orientação a objetos possui algumas limitações nas tarefas de projetar
Leia maisINSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE
1 INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE Nickerson Fonseca Ferreira nickerson.ferreira@ifrn.edu.br O que é?? 2 A UML
Leia maisUML Diagrama de Atividades Diagrama de Caso de Uso. ENG1518/3VB Sistemas de Informação Gerenciais Prof. Marcos Villas
Diagrama de Atividades Diagrama de Caso de Uso ENG1518/3VB Sistemas de Informação Gerenciais Prof. Marcos Villas villas@puc-rio.br 1 - Conceitos 2 UML é uma linguagem para: Especificar Visualizar Construir...
Leia maisSeminário de aspectos: conceitos, características e exemplos
Seminário de aspectos: conceitos, características e exemplos Daniel Bruno Conrado Thiago Gottardi Departamento de Computação Universidade Federal de São Carlos (UFSCar) São Carlos SP Brasil dbconrado@gmail.com,
Leia maisCLÁUDIO ROSSE PANDOLFI SUPORTE DE INTERESSES TRANSVERSAIS PARA FRAMEWORK CODEIGNITER
FUNDAÇÃO DE ENSINO EURÍPIDES SOARES DA ROCHA CENTRO UNIVERSITÁRIO EURÍPIDES DE MARÍLIA UNIVEM CURSO DE CIÊNCIA DA COMPUTAÇÃO CLÁUDIO ROSSE PANDOLFI SUPORTE DE INTERESSES TRANSVERSAIS PARA FRAMEWORK CODEIGNITER
Leia maisQualidade de Software: Visão Geral. Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa
Qualidade de : Visão Geral Engenharia de Profa. Dra. Elisa Yumi Nakagawa 1 o semestre de 2017 Qualidade de Qualidade é um termo que pode ter diferentes interpretações. Existem muitas definições de qualidade
Leia maisMANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO
MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO Sumário PREFÁCIO...3 MODELO DA DOCUMENTAÇÃO...3 1. INTRODUÇÃO AO DOCUMENTO...3 1.1. Tema...3 2. DESCRIÇÃO
Leia maisEngenharia de Software
Engenharia de Software Visão Geral Profa.Paulo C. Masiero masiero@icmc.usp.br ICMC/USP Algumas Dúvidas... Como são desenvolvidos os softwares? Estamos sendo bem sucedidos nos softwares que construímos?
Leia maisUm Perfil UML para Frameworks Transversais
Um Perfil UML para Frameworks Transversais Aluno: José Uetanabara Júnior 1 Orientador: Valter Vieira de Camargo 2 ¹Instituto de Informática Univem Centro Universitário Eurípides de Marília Marília, São
Leia maisCiência da Computação. Análise e Projeto Orientado a Objetos UML. Anderson Belgamo
Ciência da Computação Análise e Projeto Orientado a Objetos UML Anderson Belgamo 1 Evolução do Software O rápido crescimento da capacidade computacional das máquinas resultou na demanda por sistemas de
Leia maisEscopo: PROCESSOS FUNDAMENTAIS
Escopo: PROCESSOS FUNDAMENTAIS Etapa:Desenvolvimento de software Disciplina: Auditoria & Qualidade em Sistemas de Informação Professor: Lucas Topofalo Integrantes: Joel Soares de Jesus Luiz R. Bandeira
Leia maisCampus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /
Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: ENGENHARIA DE SOFTWARE Aula N : 16 Tema:
Leia maisDIAGRAMAS DE CLASSE UML
DIAGRAMAS DE CLASSE UML Projeto Detalhado de Software (PDS) Profa. Cynthia Pinheiro Antes de mais nada... Calendário de Reposições Aula 1: 27/10/2017, 8h-10h, Sala 8 Aula 2: A verificar Aula 3: A verificar
Leia maisEngenharia de Software 2012/3 Aula 5 Modelagem de Sistemas
Engenharia de Software Engenharia de Software 2012/3 Aula 5 Modelagem de Sistemas Thiago P. da Silva thiagosilva@ufmt.br Agenda Modelagem de Sistemas Modelos de contexto Diagramas de Atividades Modelos
Leia maisCurso de Sistemas de Informação. Karla Donato Fook DESU / DComp. Modelagem de Dados UML
Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DComp 2017 Modelagem de Dados UML 2 1 Eduardo Bezerra Editora Campus/Elsevier Porcentagem de projetos que terminam dentro do
Leia mais5 A Linguagem de Modelagem asideml
5 A Linguagem de Modelagem asideml Este Capítulo descreve uma abordagem para tratar do problema da necessidade de linguagens de modelagem mais expressivas, apresentado no Capítulo 1. Em particular, ele
Leia maisTópicos da Aula. A Linguagem UML. A Linguagem UML. De onde surgiu? Fundadores da UML. Introdução à UML e Diagrama de Casos de Uso.
Engenharia de Software Aula 07 Tópicos da Aula Introdução à UML e Introdução a UML Visão geral de alguns diagramas Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 28 Março 2012 A
Leia maisUNIVERSIDADE LUSÍADA DE LISBOA. Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2017/2018
Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2017/2018 1. Unidade Orgânica Ciências da Economia e da Empresa (1º Ciclo) 2. Curso Engenharia Informática 3. Ciclo de Estudos 1º 4. Unidade
Leia maisENGENHARIA DE SOFTWARE
EMENTA ENGENHARIA DE SOFTWARE DISCIPLINA: Estrutura e Fluxo de Informação EMENTA: A disciplina Estrutura e Fluxo de Informação se propõe a capacitar o aluno sobre os fundamentos da Gestão da Informação
Leia maisProcesso. Processo unificado. Principais Características do UP. Principais Características do UP RUP. Unified Process (Processo Unificado)
Processo UP Unified Process (Processo Unificado) Conjunto de passos que tem como objetivo atingir uma meta Processo de software na ES, processo que visa a produzir o software - de modo eficiente e previsível
Leia maisUma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos
Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos Vinicius Cardoso Garcia 1, Daniel Lucrédio 1, Luíza Frota de Paula Pinto 1, Alexandre Alvaro 2, Eduardo Santana de Almeida 2,
Leia maisA Arquitetura de Software ArchM
5 A Arquitetura de Software ArchM Como dito anteriormente, uma possível solução para o problema de separação de mobilidade em SMAs, investigada neste trabalho, envolve o DSOA. Nosso trabalho propõe: (1)
Leia mais132 6 Conclusão 6.1. Contribuições da Tese
132 6 Conclusão Esta tese teve como objetivo principal o estudo da aplicação de transformações para manter a rastreabilidade de um sistema de software. Esta abordagem permite a captura automática das informações
Leia maisCapítulo 5 Modelação do Sistema 1
Capítulo 5 Modelação do Sistema Capítulo 5 Modelação do Sistema 1 Assuntos abordados Modelos de contexto Modelos de interação Modelos estruturais Modelos comportamentais Engenharia orientada a modelos
Leia maisUNIVERSIDADE LUSÍADA DE LISBOA. Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2013/2014
Programa da Unidade Curricular PROGRAMAÇÃO AVANÇADA Ano Lectivo 2013/2014 1. Unidade Orgânica Ciências da Economia e da Empresa (1º Ciclo) 2. Curso Engenharia Informática 3. Ciclo de Estudos 1º 4. Unidade
Leia maisUm Método para o Desenvolvimento de Software Baseado em Componentes e Aspectos
Roteiro Um Método para o Desenvolvimento de Software Baseado em Componentes e Aspectos Marcelo Medeiros Eler Universidade de São Paulo Av. do Trabalhador São-Carlense, 400 São Carlos, SP Email: mareler@icmc.usp.br
Leia maisCiclo de vida: fases x atividades
Ciclo de vida Fase de definição Análise e Especificação Estudo de Viabilidade Estimativas Planejamento Fase de desenvolvimento Design Implementação e integração Verificação e Validação Fase de operação
Leia mais15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos
DCC / ICEx / UFMG Pensar Orientado a Objetos Projeto Orientado a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Onde quer que você olhe no mundo real, você vê objetos Pessoas, animais, plantas,
Leia maisAPÊNDICE D Unified Model Language (UML)
APÊNDICE D Unified Model Language (UML) 299 APÊNDICE D Unified Model Language (UML) Apresenta-se neste Apêndice uma visão geral sobre a UML (Unified Modeling Language), focalizando-se nos conceitos e definições
Leia maisIntrodução a UML (Unified Modeling Language)
Introdução a UML (Unified Modeling Language) O que é a UML? Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário
Leia maisEngenharia de Software Orientada a Objetos - OOSE. Método de Jacobson
Engenharia de Software Orientada a Objetos - OOSE Método de Jacobson Alunos: Amanda Lira Gomes Lucas Balbino de Melo Ferreira Mycke Richard Guntijo Renato Gomes Borges Júnior Sumário Introdução Visão Geral
Leia maisComo Modelar com UML 2
Ricardo Pereira e Silva Como Modelar com UML 2 Visual Books Sumário Prefácio... 13 1 Introdução à Modelagem Orientada a Objetos... 17 1.1 Análise e Projeto Orientados a Objetos... 18 1.2 Requisitos para
Leia maisEngenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS. Nome:
Engenharia de Software Simulado para a 1ª Avaliação Bimestral Professor: Danilo Giacobo - RESPOSTAS Nome: 1. A figura abaixo representa, simplificadamente, as fases do Modelo de Ciclo de Vida Cascata.
Leia mais5 METODOLOGIA PROPOSTA
5 METODOLOGIA PROPOSTA 179 5 METODOLOGIA PROPOSTA 5.1 Introdução Primeiramente neste capítulo, introduz-se uma proposta de estruturação para o processo de especificação e projeto de sistemas de automação
Leia maisUML Unified Modeling Language Linguagem de Modelagem Unificada
UML Unified Modeling Language Linguagem de Modelagem Unificada Prof. Gilberto Porto e-mail: porto@gilbertoporto.com.br A linguagem UML n UML (Unified Modeling Language) Linguagem de Modelagem Unificada
Leia maisAula 1 - Introdução à disciplina e Processos de desenvolvimento de software e suas atividades básicas
Aula 1 - Introdução à disciplina e Processos de desenvolvimento de software e suas atividades básicas Análise de Sistemas Prof. Filipe Arantes Fernandes filipe.arantes@ifsudestemg.edu.br Nome da disciplina:
Leia maisQualidade de Software: Visão Geral. SSC 121-Engenharia de Software 1 Profa. Dra. Elisa Yumi Nakagawa
Qualidade de : Visão Geral SSC 121-Engenharia de 1 Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012 Qualidade de Qualidade é um termo que pode ter diferentes interpretações Existem muitas definições
Leia maisIntrodução. à UML. Histórico (cont.) Histórico Definição Benefícios Notação Diagrama de Classes Diagramas de Interação Conclusões Revisão
Sumário Introdução à UML BSI Bacharelado em Sistemas de Informação LOO Linguagens Orientadas a Objetos Humberto Mossri de Almeida hmossri_cursos@yahoo.com.br Marcelo Nassau Malta nassau_cursos@yahoo.com.br
Leia maisLista Diagrama de Casos de Uso
Lista Diagrama de Casos de Uso 1. Qual é a notação da UML para um caso de uso? Qual é a notação da UML para um ator? Qual a notação utilizada na UML para o relacionamento de generalização? 2. Defina o
Leia maisDocumento de Análise e Projeto Versão 1.0
Documento de Análise e Projeto Versão 1.0 Histórico de Revisões Data Versão Descrição Autor 27/10/2010 1.0 Elaboração da versão inicial do documento de análise e projeto Bruno Macena Felipe Souza Rui Fonte
Leia maisMODELAGEM DE DADOS MÓDULO III - UNIDADE V- MAPEAMENTO OBJETO RELACIONAL
MODELAGEM DE DADOS MÓDULO III - UNIDADE V- MAPEAMENTO OBJETO RELACIONAL 0 UNIDADE V: MAPEAMENTO OBJETO RELACIONAL Paradigma da Orientação a Objetos: Este paradigma parte do princípio que existem diversos
Leia maisUma Abordagem para Engenharia de Requisitos no Domínio de Software Embarcado
Uma Abordagem para Engenharia de Requisitos no Domínio de Software Embarcado Milena R. S. Marques, Eliane Siegert, Lisane de Brisolara Ciência da Computação, Grupo de Arquiteturas e Circuitos Integrados,
Leia maisConteúdo. Disciplina: INF Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 09289 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 3. Especificação e Análise de Requisitos
Leia mais6.1. Teste Baseado em Gramática e Outras Abordagens de Teste
6 Discussão Além das técnicas de teste usando modelos gramaticais, existem outras abordagens de teste funcional de sistemas que estão sendo estudadas pela comunidade científica. Algumas delas se dedicam
Leia mais10/10/2012. Artigo: Autores:
Artigo: Apresentar um estudo sistemático sobre as métricas de acoplamento na Programação Orientada a Aspectos e seu impacto na manutenibilidade e estabilidade do projeto. Autores: Rachel Burrows, Alessandro
Leia maisEspecificação de Sistemas de Software e a UML
Modelagem de sistema Especificação de Sistemas de Software e a UML A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema Modelo => visão simplificada e abstrata de um sistema
Leia maisRequisitos de Sistemas
Requisitos de Sistemas Unidade I - Engenharia de Requisitos Definição de Requisitos (Continuação) Processos de Engenharia de Requisitos (Cont.) - Análise - Registro - Validação - Gerência 1 Processo de
Leia maisUML (Unified Modelling Language)
UML (Unified Modelling Language) Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Booch, G. et al. The Unified Modeling Language User Guide
Leia maisDesenvolvimento de Software. Testes de Software. Tópicos da Aula. Onde estamos... Verificação x Validação. Testes de Software
Engenharia de Software Aula 17 Desenvolvimento de Software Testes de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo dcc603@gmail.com 7 Maio 2012 1. Especificação de requisitos 2. Projeto
Leia maisExtração de Aspectos. PUC Minas Instituto de Informática. Mestrado em Informática. Aluno: Marcelo Nassau Malta
Transformações de Código C para Extração de Aspectos PUC Minas Instituto de Informática Mestrado em Informática Aluno: Marcelo Nassau Malta Orientador: Prof. Marco Túlio de Oliveira Valente Sumário Motivação
Leia maisO Fluxo de Requisitos
O Fluxo de 1 Finalidade do fluxo de requisitos A finalidade deste fluxo é: Chegar a um acordo com o cliente e o usuário sobre o que o sistema deve fazer. Oferecer ao desenvolvedor um melhor entendimento
Leia maisIntrodução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.
Diagramas UML Classe, Seqüência e Atividades Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 15 de maio
Leia maisUML. Adriano J. Holanda 21/3/
UML Adriano J. Holanda 21/3/2016 UML Introdução UML - Unified Modeling Language Linguagem Unificada de Modelagem. Adquiriu maturidade na segunda década de 1990 pela fusão dos métodos e diagramas de Grady
Leia maisRequisitos de Sistemas
Requisitos de Sistemas Unidade II - Processos de Negócio Identificação Conceitos Modelagem - BPM - UML Processos x Requisitos 1 Processo de negócio CONCEITO Um processo de negócio, processo organizacional
Leia maisEngenharia de Software
PLANO DE AVALIAÇÕES Engenharia de Software 1ª AP: 08 de setembro 2ª AP: 13 de outubro 3ª AP: 10 de novembro NAF: 17 de novembro Referência bibliográfica: SOMMERVILLE, I. Engenharia de Software. 8ª ed.
Leia maisA Linguagem UML. A Linguagem UML. De onde surgiu? Fundadores da UML. História da UML. O que é modelagem?
DCC / ICEx / UFMG A Linguagem UML A Linguagem UML Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo UML (Linguagem de Modelagem Unificada) É uma notação gráfica (visual) para projetar sistemas OO Não
Leia maisPrincípios da Engenharia de Software aula 03
Princípios da Engenharia de Software aula 03 Prof.: José Honorato Ferreira Nunes Material cedido por: Prof.: Franklin M. Correia Na aula anterior... Modelos de processos de software: Evolucionário Tipos
Leia maisEngenharia de Requisitos
Engenharia de Requisitos Criado: mar/2001 Atualizado: set/2005 Tópicos Definição de Requisitos Participantes Processo Documento de Requisitos (SRS) Evolução dos Requisitos 2 Referência I.Sommerville. Sw
Leia maisProf. Esp. Fabiano Taguchi
UML Prof. Esp. Fabiano Taguchi http://fabianotaguchi.wordpress.com fabianotaguchi@hotmail.com UML COMPETÊNCIA: Conhecer e desenvolver estudos de caso usando modelagem orientada a objeto. HABILIDADE: Conhecer
Leia maisIntrodução. Diagramas de Interação. Introdução. Introdução. Introdução. Introdução. Os modelos de análise não respondem a algumas perguntas:
Diagramas de Interação Os modelos de análise não respondem a algumas perguntas: Como as operações do sistema são executadas internamente? A que classes estas operações internas pertencem? Quais objetos
Leia mais3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks
48 3 Uma Abordagem Orientada a Aspectos para o Desenvolvimento de Frameworks Este capítulo apresenta uma visão geral da contribuição principal deste trabalho: uma abordagem orientada a aspectos para o
Leia maisProf. Ms. Ronaldo Martins da Costa
Prof. Ms. Ronaldo Martins da Costa Diferentes conjuntos de etapas que envolvem métodos, ferramentas e procedimentos utilizados no desenvolvimento de software CiclodeVidaClássico Prototipação Modelo Espiral
Leia maisUML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos
UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos joao.queiroz@ifrn.edu.br Roteiro A importância da UML para projetar sistemas. Principais características do diagrama de classes e de sequência.
Leia maisModelagem Orientada a Objetos
DCC / ICEx / UFMG Modelagem Orientada a Objetos Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Atividades de Modelagem OO 1. Definir o contexto do sistema 2. Projetar a arquitetura 3. Identificar
Leia maisEngenharia de Software I
Engenharia de Software I Fundamentos da Engenharia de Software Modelos de desenvolvimento Importância do software Importância do Software Qualidade é fundamental Consequências de erros no software podem
Leia mais2 Fluxos no Ciclo de Vida do Processo Unificado. O Processo Unificado consiste da repetição de uma série de ciclos durante a vida de um sistema.
Processo Unificado Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Ciclo de Vida - Fluxos Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre
Leia mais2. Trabalhos Relacionados
19 acase: Ambiente para Modelagem, Geração de Código e Engenharia Reversa de Software Orientado a Aspectos Thiago Silva-de-Souza¹, ², Wallace Santos Vialle Rettich², Danilo Ferreira Leite², Diego Cardozo
Leia maisProcessos de software
Processos de software 1 Processos de software Conjunto coerente de atividades para especificação, projeto, implementação e teste de sistemas de software. 2 Objetivos Introduzir modelos de processos de
Leia maisCAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS. Tereza Gonçalves Kirner
CAPÍTULO 1 O AMBIENTE DE DESENVOLVIMENTO DE SISTEMAS Tereza Gonçalves Kirner Apresentação elaborada com base em: Hoffer, Jeffrey A., George, Joey F. Modern Systems Analysis and Design (Capítulo 1), Pearson,
Leia maisEngenharia de Software I Processos de desenvolvimento de SW. profa. Denise Neves
I Processos de desenvolvimento de SW profa. Denise Neves profa.denise@hotmail.com 2018 Projeto Um projeto é um empreendimento temporário empreendido para alcançar um único conjunto de objetivos. (PMI,PMBOK
Leia maisAula 7 - Análise de Requisitos: descrição de casos de uso. Análise de Sistemas Prof. Filipe Arantes Fernandes
Aula 7 - Análise de Requisitos: descrição de casos de uso Análise de Sistemas Prof. Filipe Arantes Fernandes filipe.arantes@ifsudestemg.edu.br Outline Introdução aos Casos de Uso Razões para utilizar Casos
Leia maisModelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Prof. Responsáveis Wagner Santos C. de Jesus
Curso Disciplina Linguagem de Programação II Curso Engenharia da Computação Modelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Site : http://www1.univap.br/~wagner/ec.html Prof. Responsáveis
Leia maisIntrodução. Introdução. Introdução. Planejamento da disciplina. Modelagem de Processos de Negócio. Prof.: Clarindo Isaías Pereira da Silva e Pádua
Modelagem de Processos de Negócio Prof.: Clarindo Isaías Pereira da Silva e Pádua Gestus Departamento de Ciência da Computação - UFMG Bibliografia Eriksson, H-E; Penker, M. Business Modeling with UML:
Leia mais27) Em relação aos Projetos de Sistemas de Software, assinale a sequência correta de desenvolvimento de um sistema:
Modelos de Ciclo de Vida e Metodologias de Software 33) No SCRUM, uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto é denominada: A) Backlog. B) Sprint. C) Daily scrum. D)
Leia maisCombinação e Aplicação de Técnicas para o Desenvolvimento de Software Orientado a Aspectos
Combinação e Aplicação de Técnicas para o Desenvolvimento de Software Orientado a Aspectos Gabriel Costa Silva, Munif Gebara Junior, Daniela Eloise Flor Curso de Sistemas de Informação, Universidade Paranaense
Leia maisCurso SISTEMAS DE INFORMAÇÃO Série 3 Disciplina Análise e Projeto Orientados a Objetos
Curso SISTEMAS DE INFORMAÇÃO Série 3 Disciplina Análise e Projeto Orientados a Objetos Prova A 01)O que é UML (Unified Modeling Language)? Cite pelo menos três exemplos de diagramas Comportamentais e três
Leia maisProf. Fábio Lúcio Meira
Prof. Fábio Lúcio Meira Objetivo Transformar os requisitos no design do futuro sistema Evoluir uma arquitetura robusta do sistema Adaptar o design para adequá-lo ao ambiente de implementação O principal
Leia mais- Engenharia Reversa - Evolução de Sofware. Desenvolvimento como. Requisitos o que. Sistema porque. Profa. Dra. Sandra Fabbri. operacional.
Unidade V Evolução de Sofware - Engenharia Reversa - Profa. Dra. Sandra Fabbri Fases Genéricas do Ciclo de Vida Engenharia Sistemas Análise Projeto Codificação Manutenção Teste Sistema Requisitos Desenvolvimento
Leia mais