ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE

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

Download "ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE"

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO SILVANO NOGUEIRA BUBACK ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Vitória

2 SILVANO NOGUEIRA BUBACK ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Monografia apresentada à Universidade Federal do Espírito Santo como requisito parcial para obtenção do título de Bacharel em Ciência da Computação, na área de concentração de Sistemas de Informação. Orientador: Ricardo de Almeida Falbo Vitória Outubro,

3 Silvano Nogueira Buback ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Aprovada em 22 de outubro de COMISSÃO EXAMINADORA Prof. Ricardo de Almeida Falbo, D.Sc. Orientador Prof. Davidson Cury, D.Sc. Prof. Julio César Nardi, M.Sc. 3

4 Agradecimentos principalmente para Deus, pois sem ele nada faria sentido. Aos meus pais, pois deles tive todo o apoio necessário para chegar até aqui. Ao Falbo, pela orientação e paciência. 4

5 RESUMO ODEDoc: Uma Ferramenta de Apoio à Documentação no Ambiente ODE Silvano Nogueira Buback Outubro de 2007 Orientador: Prof. Ricardo de Almeida Falbo A necessidade cada vez mais freqüente por softwares e estes cada vez mais complexos trazem desafios aos engenheiros de software, principalmente no que diz respeito à manutenibilidade desses sistemas. A atividade de documentação visa apoiar a manutenibilidade dos sistemas, porém, para reduzir custos e compensar atrasos, principalmente da fase de desenvolvimento, a documentação é colocada em segundo plano, reduzindo a qualidade do software construído e aumentando o custo da manutenção. O uso de uma ferramenta que apóie a geração dos documentos pode tornar a atividade de documentação mais rápida, além de facilitar a atualização quando tais documentos são alterados. Ainda, a criação de modelos de documento facilita a padronização dos documentos de uma corporação. Neste trabalho foi construída a ferramenta ODEDOC, uma ferramenta de apoio à documentação para o ambiente ODE (Ontology-based software Development Environment). É apresentado como a ferramenta foi construída e mostrado como ela pode facilitar a geração e atualização dos documentos pelo uso de modelos de documentos. Palavras chave: Documentação, Modelos de Documento, Ambiente de Desenvolvimento de Software. 5

6 SUMÁRIO Capítulo 1 - Introdução Objetivo Metodologia Capítulo 2 - Automatização do Processo e Documentação CASE I-CASE Framework de Integração Problemas relacionados à integração Ambientes de Desenvolvimento de Software O Ambiente ODE Documentação de Software Capítulo 3 - Especificação de Requisitos Requisitos Funcionais Caso de Uso Editar Modelo de Documento Caso de Uso Editar Modelo de Seção Caso de Uso Editar Documento Formatado Caso de Uso Editar Seção Caso de Uso Gerar Documento Formatado Especificação de Requisitos Não Funcionais Manutenibilidade Usabilidade Capítulo 4 - Análise Modelo de Classes Pacote Controle Pacote Conhecimento Pacote Documentacao Modelagem comportamental Capítulo 5 - Projeto Plataforma de implementação Arquitetura Pacote Conhecimento.documentacao

7 5.3.1 Pacote cdp Pacote cgd Pacote cgt Pacote cih Pacote cci Pacote Ode.documentacao Pacote cdp Pacote cgd Pacote cgt Pacote cih Pacote cci Implementação Gerar Documento Formatado Testes Capítulo 6 - Conclusões e Perspectivas Futuras Conclusões Perspectivas futuras

8 INDÍCE DE FIGURAS Figura Arquitetura Conceitual de ODE Figura Ontologia de Artefato (NUNES et al., 2004) Figura Ontologia de Documentos de Software Figura Diagrama de Casos de Uso Figura Diagrama de pacotes Figura Diagrama de classes parcial do pacote Ode.ControleProcesso Figura Diagrama de classes do pacote Ode.Conhecimento.Documentacao Figura Diagrama de classes do pacote Ode.Documentacao Figura 4.6 Caso de Uso Exportar Documento Figura Arquitetura em camadas Figura 5.2 Comparação entre modelo MVC e o modelo adotado no Ode Figura Dependência de pacotes de todo o sistema Figura Pacote Conhecimento.documentacao.cdp Figura Pacote Conhecimento.documentacao.cgd Figura Pacote Ode.Conhecimento.Documentacao.Cgt Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cih Figura Janela de seleção dos modelos de documentos Figura Janela de edição dos dados do modelo de documento Figura Janela de edição dos dados do modelo de seção Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cci Figura Pacote documentacao.cdp Figura Pacote documentacao.cgd Figura Pacote documentacao.cgt Figura Diagrama de classes do pacote documentacao.cih Figura Janela de edição dos dados do documento formatado e das seções Figura Diagrama de classes do pacote ode.conhecimento.documentacao.cci

9 Capítulo 1 - Introdução A documentação de software tem a finalidade de comunicar informações sobre o sistema de software ao qual ela pertence (FORWARD, 2002). Em outras palavras, documentar é comunicar. Porém a comunicação informal, essencialmente baseada em palavras, não é suficiente. Além da facilidade de ocorrerem distorções na compreensão, termo popularmente conhecido como telefone sem fio, ela não é capaz de resistir ao tempo e não é prática quando a quantidade de pessoas envolvidas no projeto é muito alta ou quando o mesmo tem rotatividade alta. Por isto, um processo formal de documentação se faz necessário. Assim, a documentação assume um papel imprescindível no processo de desenvolvimento de software, visto que a mesma está presente em todas as fases do ciclo de vida do software (PRESSMAN, 2002). Como a demanda por software cresce continuamente, principalmente no que diz respeito a problemas que pedem soluções mais complexas, muitas vezes o trabalho de se documentar torna-se deveras oneroso, sendo usualmente posto de lado em detrimento a outras atividades, tal como a codificação. Contudo, o engenheiro de software deve possuir em mente que, sem uma documentação consistente e detalhada, é praticamente impossível garantir a manutenibilidade. 1.1 Objetivo O objetivo deste trabalho é desenvolver uma ferramenta de apoio à documentação que possa auxiliar na geração da documentação do projeto. O objetivo não é somente gerar a primeira documentação, mas sim auxiliar na manutenção da mesma, permitindo que as alterações feitas no projeto possam ser refletidas nos documentos. Ainda, é fundamental que a geração de documentos seja integrada ao ambiente ODE (Ontology-based software Development Environment) (FALBO et al., 2003), o Ambiente de Desenvolvimento de Software (ADS) em desenvolvimento no Laboratório de Engenharia de Software da Universidade Federal do Espírito Santo (LabES). A integração da ferramenta de apoio à 9

10 documentação a ODE vai permitir que as várias ferramentas do ambiente possam utilizá-la, evitando a construção de soluções isoladas de documentação, o que pode comprometer a integração de ferramentas. Como diferencial em relação aos outros dois trabalhos de pesquisa sobre documentação desenvolvidos para o ODE (SOARES, 2002) (SILVA, 2004), este trabalho tem por objetivo tornar a documentação um processo simples de ser feito, não sendo necessários conhecimentos sobre XML, HTML ou qualquer outra tecnologia. O objetivo é que o gerente de documentação conheça apenas o ADS ODE. 1.2 Metodologia A metodologia adotada no desenvolvimento deste trabalho pode ser dividida em três fases: revisão bibliográfica sobre ferramentas CASE e ADS, definição do escopo do trabalho e desenvolvimento. Ainda na fase de revisão bibliográfica foi delimitado o escopo inicial do trabalho, porém, esse escopo original incluía também a persistência de artefatos em XML para apoiar a ferramenta de gerência de configuração (NUNES, 2005). Na fase de definição do escopo, decidiu-se abandonar essa idéia, concentrando a atenção deste trabalho apenas na documentação de artefatos produzidos internamente a ODE. A motivação para retirar a persistência de artefatos em XML surgiu da separação entre a documentação e a gerência de configuração. A geração dos artefatos em XML permitia atender às duas soluções, porém não atendia de forma razoável a nenhuma das duas. Na documentação, o uso do artefato em XML facilitava a leitura dos dados, porém exigia a construção das folhas de estilo para gerar a apresentação, uma tarefa que exigia um conhecimento técnico sobre XML e tecnologias relacionadas. Na gerência de configuração, as versões antigas dos artefatos não podiam ser manipuladas de forma transparente pelas ferramentas, impedindo que dois usuários fossem capazes de visualizar, através da ferramenta que as gerou, duas versões distintas de um mesmo artefato. 10

11 1.3 Organização da monografia Além deste capítulo, esta monografia contém mais cinco capítulos, a saber: Capítulo 2 Automatização do Processo e Documentação: neste capítulo discute-se a evolução das ferramentas CASE até os se chegar aos ADSs. Também é enfatizada a importância da documentação de software, além de uma breve apresentação do ADS ODE; Capítulo 3 Especificação de Requisitos: neste capítulo são apresentados os requisitos funcionais e não-funcionais para o desenvolvimento da ferramenta de apoio à documentação; Capítulo 4 Análise: neste capítulo é apresentada a modelagem de análise da aplicação, com diagramas de classes e de seqüência; Capítulo 5 Projeto: é apresentado o projeto da ferramenta, levando em consideração os aspectos tecnológicos e requisitos. Também neste capítulo são descritas as estratégias de implementação e testes; Capítulo 6 Conclusões e Perspectivas Futuras: neste capítulo é explicado como este trabalho poderá ajudar na atividade de documentação além de melhorias e trabalhos futuros que poderão surgir. 11

12 Capítulo 2 - Automatização do Processo e Documentação Há um provérbio árabe que diz: Conheces um trabalhador pelas tuas ferramentas. Um engenheiro de software, hoje, conhece bem a aplicação desse ditado. Com softwares cada vez mais complexos, prazos mais curtos e a necessidade de custos menores, em função de um mercado cada vez mais competitivo, o desenvolvimento de software tornou-se uma tarefa árdua. Levantar requisitos, gerar documentação, acompanhar cronograma, gerenciar riscos, codificar, testar, implantar são algumas das atividades presentes em qualquer ciclo de desenvolvimento de software que se tornaram praticamente impossíveis de realizar sem o uso de ferramentas adequadas. Neste capítulo examinamos a evolução das ferramentas CASE (Computer-Aided Software Engineering) e a necessidade da documentação de software, terminando com a apresentação do projeto no qual a ferramenta desenvolvida por este trabalho está inserida 2.1 CASE Existem muitas definições para CASE. Segundo (PRESSMAN, 2002), CASE é uma ferramenta de software apoiada por computador, que assiste gerentes e profissionais de engenharia de software em toda atividade associada com o processo de software. Ferramentas CASE automatizam as atividades de gestão de projetos, gerenciam todos os produtos de trabalho produzidos ao longo do processo e assistem os engenheiros em seu trabalho de análise, projeto, codificação e teste. Já o Instituto de Engenharia de Software (Software Engineering Institute SEI) (SEI, 2007) define CASE de uma forma bem direta: CASE é o apoio do computador no processo de desenvolvimento de software. Essencialmente, a definição do SEI é mais ampla, não restringindo o conceito de CASE apenas a software. Em (PRESSMAN, 2002) foi criada uma taxonomia para essas ferramentas, utilizando como critério a função à qual ela é aplicada. A seguir temos uma lista dos grupos de ferramentas: 12

13 Ferramentas de engenharia de processos de negócio; Ferramentas de modelagem e gestão de processo; Ferramentas de planejamento de projeto; Ferramentas de análise de riscos; Ferramentas de gestão de projetos; Ferramentas de rastreamento de requisitos; Ferramentas de métricas e gestão; Ferramentas de documentação; Ferramentas de software básico; Ferramentas de garantia da qualidade; Ferramentas de gestão de bases de dados; Ferramentas de gestão de configuração de software; Ferramentas de análise e projeto; Ferramentas de prototipação / simulação; Ferramentas de projeto e desenvolvimento de interfaces; Ferramentas de programação; Ferramentas de desenvolvimento Web; Ferramentas de integração e testes; Ferramentas de análise estática; Ferramentas de análise dinâmica; Ferramentas de gestão de testes; Ferramentas de teste cliente/servidor; Ferramentas de reengenharia; Apesar da evolução permanente dessas ferramentas, elas não substituem práticas confiáveis de engenharia de software. Elas devem ser utilizadas apenas para complementá-las. Sem um processo de software estabelecido, métodos de engenharia de software e qualidade aprendidos, o uso dessas ferramentas CASE pode vir a prejudicar o bom andamento do projeto, tornando-o burocrático e confuso (PRESSMAN, 2002). 13

14 2.2 I-CASE As etapas de desenvolvimento de software são todas interligadas. Os métodos utilizados para realizar os testes, ao final do processo de desenvolvimento, estão intimamente ligados aos requisitos colhidos no início do projeto. Isso torna necessária uma integração muito ampla por parte das ferramentas CASE. Ferramentas isoladas são muito úteis em determinadas etapas, porém os resultados obtidos pela integração podem ser muito maiores. À ferramenta CASE integrada dá-se o nome de I-CASE (Integrated CASE) (PRESSMAN, 2002). De fato, a integração de ferramentas não é uma tarefa muito simples de ser feita, principalmente, considerando que, apesar do processo de desenvolvimento de software ser todo integrado, significados diferentes são atribuídos às informações durante cada etapa do desenvolvimento. Uma ferramenta CASE totalmente integrada deve refletir todas as peculiaridades do processo de desenvolvimento, enfatizando as necessidades de cada etapa. Apesar do significado que cada informação possui para determinada ferramenta, estas não podem perder o significado global da informação. Por exemplo, um diagrama de classes é feito a partir dos requisitos levantados do sistema. A partir dele pode-se derivar o modelo relacional. Porém, se um requisito a mais for considerado, este pode, por exemplo, implicar na adição de um atributo em alguma classe. O atributo em questão deve ser adicionado ao código fonte e, também, deve ser propagado para o modelo relacional. Apesar dos modelos serem aparentemente diferentes, todos fazem parte do contexto do software que está sendo desenvolvido. As alterações feitas em algum dos modelos têm impacto em muitos outros Framework de Integração Em relação à integração, há dois pontos de visão distintos: o ambiente do ponto de vista do usuário e o ambiente do ponto de vista do construtor. O ambiente do usuário é voltado para interface. Este quer ver o quanto bem integrado está às ferramentas. Já o construtor de ferramentas, preocupa-se 14

15 com o quão fácil é integrar uma ferramenta ao ambiente (THOMAS et al., 1992). De acordo com o modelo de referência proposto em (THOMAS et al., 1992), há quatro dimensões de integração: Integração de dados: é suportada pelo repositório e serviços de integração de dados; Integração de controle: é suportada pela gerência de processos e serviços de mensagens; Integração de apresentação: é suportada pelos serviços de interface com o usuário; Integração de processo: garante que a ferramenta interage efetivamente no apoio a um processo definido. Integração de dados A informação manipulada pelas ferramentas inclui dados persistentes e não-persistentes (que não sobrevivem após a execução das ferramentas e que são compartilhados e trocados entre elas). O objetivo é manter a informação consistente, independentemente de quantas partes estão sendo operadas e transformadas pelas ferramentas (THOMAS et at., 1992). Integração de Controle Para ferramentas compartilharem funcionalidades, elas precisam ser capazes de comunicar as operações que devem ser executadas. Como as operações requerem dados, as ferramentas também devem comunicar ou referenciar dados. Neste contexto, a integração de controle complementa a integração de dados. Integração de dados diz respeito à representação dos dados, conversão e tarefas de armazenamento. Integração de controle diz respeito à transferência, controle e compartilhamento de serviços (THOMAS et at., 1992). Integração de Apresentação O objetivo da integração de apresentação é aumentar a eficiência e a efetividade da interação do usuário com o ambiente, reduzindo o esforço cognitivo (THOMAS et at., 1992). Ela diz respeito à forma como os dados são 15

16 apresentados e os recursos acessados. A uniformização da apresentação torna o aprendizado de ferramentas novas muito mais rápido e fácil Integração de Processos O objetivo da integração de processo é garantir que as ferramentas interagem de forma eficaz com base em um processo definido. Uma ferramenta incorpora um conjunto de concepções sobre o processo que pode ser usado. Duas ferramentas são bem integradas em relação ao processo se suas concepções são consistentes (THOMAS et at., 1992) Problemas relacionados à integração A maior parte das pesquisas e desenvolvimento de ferramentas CASE integradas está focada na infra-estrutura e mecanismos para integração, como funcionalidades de usuários e mecanismos de troca de dados entre as ferramentas. Não há tantas pesquisas referentes à semântica dos dados, sendo esta o objetivo final da integração: integrar ferramentas sem que elas percam a semântica da informação que está sendo manipulada. Também há problemas de muitas ferramentas CASE não terem sido implementadas em uma arquitetura em que a integração fosse possível. Desta forma, seria necessário remodelar toda ferramenta, o que é, na maioria das vezes, inviável para os negócios da empresa. Questões de estratégia por parte das empresas também impedem a integração real. Muitas empresas já possuem, por meio de suas ferramentas, uma grande parcela do mercado. Não seria interessante para elas permitir que algumas de suas ferramentas possam ser substituídas pelas dos concorrentes. A integração ocorre apenas entre ferramentas da própria empresa desenvolvedora, ou seja, a camada de integração das ferramentas existe, em parte, porém são proprietárias. 2.3 Ambientes de Desenvolvimento de Software Como a integração de ferramentas CASE produzidas sem uma preocupação prévia com esse aspecto revelou-se utópica e a necessidade de ferramentas que apoiassem todas as etapas do desenvolvimento de software 16

17 cresce cada vez mais, começaram a surgir os Ambientes de Desenvolvimento de Software (ADSs). Um ADS apóia todas as etapas do desenvolvimento, consistindo ainda de ferramentas separadas, porém as ferramentas do ADS são construídas sobre um núcleo comum, o que facilita a integração. Um tipo de ADS merece destaque: os Ambientes de Desenvolvimento de Software Centrados em Processo. Esses ambientes exploram uma representação explícita do processo de software para guiar e auxiliar os desenvolvedores no desenvolvimento de software. Os processos são modelados no ADS e a execução dá-se quando os agentes, humanos ou não, executam as atividades decorrentes do processo. 2.4 O Ambiente ODE Ontology-based software Development Environment (ODE) é um ambiente que vem sendo desenvolvido no Laboratório de Engenharia de Software (LABES) da Universidade Federal do Espírito Santo. O ambiente é um ADS Centrado em Processo e baseado em ontologias que possui uma infra-estrutura de gerência do conhecimento. Em ODE, parte-se do pressuposto que, se as ferramentas de um ADS são construídas baseadas em ontologias, a integração delas pode ser facilitada, pois os conceitos envolvidos são bem definidos pelas ontologias (FALBO et al., 2003). Dentre as ontologias que compõem a base ontológica de ODE, tem-se a ontologias de processo de software (BERTOLLO, 2006), de qualidade de software (FALBO et al., 2002) e de artefatos de software (NUNES, 2005), utilizada neste trabalho. Para manter a amarração semântica entre os objetos de ODE e agregar as ontologias ao ambiente, foi proposta uma arquitetura de três níveis (RUY, 2006): Figura Arquitetura Conceitual de ODE 17

18 O Nível Ontológico é responsável pela descrição das ontologias. O pacote Ontologia contém as classes que definem uma ontologia de certo domínio e seus elementos. As instâncias das classes do nível ontológico servem de base para a definição das classes dos outros níveis. O Meta-Nível abriga as classes que descrevem o conhecimento em relação a um domínio de aplicação. Suas classes são derivadas das ontologias e as instâncias dessas classes atuam no papel de conhecimento sobre os objetos do nível base. Elas constituem o conhecimento do ambiente, que pode ser utilizado por qualquer ferramenta que o compõe. O Nível Base define as classes responsáveis por implementar as aplicações no contexto do ambiente (funcionalidades da infraestrutura e suas ferramentas). Essas classes são também derivadas das ontologias, mas tipicamente incorporam detalhes não descritos por elas, necessários para implementar as aplicações. 2.5 Documentação de Software Um documento de software pode ser definido como um artefato cuja finalidade é comunicar uma informação sobre o sistema de software ao qual ele pertence (FORWARD, 2002). Em outras palavras, documentar é comunicar. Segundo Ambler (AMBLER, 2004), do ponto de vista da modelagem ágil, um documento é qualquer artefato externo ao código fonte cujo propósito seja transmitir informação de uma maneira persistente. Já um modelo é uma abstração que descreve um ou mais aspectos de um problema ou de uma solução potencial para resolver um problema. Alguns modelos podem se tornar documentos, ou incluídos como parte deles, ou simplesmente serem descartados quando cumprirem seu papel. Por fim, código fonte é uma seqüência de instruções, incluindo os comentários que descrevem essas 18

19 instruções, para um sistema de computador. O termo documentação inclui documentos e comentários de código fonte. O objetivo deste trabalho é desenvolver uma ferramenta de apoio à documentação em ODE. Como foi dito anteriormente, ODE é um ADS baseado em ontologias. As ontologias são a base para a integração das ferramentas em ODE. Assim, é natural que uma ferramenta de documentação inserida no contexto de ODE seja apoiada por uma ontologia de documentos, que, por sua vez, é parte da ontologia de artefatos (NUNES et al., 2004), parcialmente mostrada na Figura 2.2. produto +super-artefato 0..* 0..* <<Conceito>> Atividade (from Ontologia de Processo) 0..* insumo dependência 0..* 0..* <<Conceito>> 0..* Artefato +sub-artefato 0..* 0..* 0..* aprovação <<Conceito>> Recurso Humano (from Ontologia de Processo) 0..* <<Conceito>> Documento <<Conceito>> Diagrama <<Conceito>> Artefato de Código <<Conceito>> Componente de Software <<Conceito>> Produto de Software Figura Ontologia de Artefato (NUNES et al., 2004) Segundo (NUNES et al., 2004), documentos são artefatos de software não passíveis de execução, constituídos tipicamente de declarações textuais, normalmente associados a padrões organizacionais (roteiros) que definem a forma como eles devem ser produzidos. Exemplos de documentos incluem documentos de especificação de requisitos, planos de projeto, planos de qualidade, relatórios de avaliação de qualidade, entre outros. A Figura 2.3 apresenta a ontologia de documento de software proposta em (NUNES et al., 2004). Os conceitos de Artefato, Procedimento e Roteiro foram importados da ontologia de processo de software (BERTOLLO, 2006), indicando a integração entre essas ontologias. 19

20 <<Conceito>> Procedimento (from Ontologia de Processo) 0..* +super-artefato +sub-artefato 0..* <<Conceito>> Artefato 0..* 0..* 0..* dependência <<Conceito>> Diretriz (from Ontologia de Processo) 0..* <<Conceito>> Roteiro (f rom Ontologia de Processo) aplicação +sub-modelo-documento <<Conceito>> Documento 1 0..* <<Conceito>> Modelo Documento 1 0..* 0..* +super-modelo-documento 0..* super-seção 0..* <<Conceito>> Seção 0..* +sub-seção 0..* correspondência * <<Conceito>> Modelo Seção opcional +modelo-super-seção 0..1 Figura Ontologia de Documentos de Software. +modelo-sub-seção 0..* De acordo com a arquitetura de ODE, apresentada na Figura 2.1, a ontologia acima vai deu origem a classes nos níveis de conhecimento e base, conforme discutido no Capítulo 5. 20

21 Capítulo 3 - Especificação de Requisitos Neste capítulo são apresentados os requisitos funcionais e nãofuncionais para o desenvolvimento da ferramenta de apoio à documentação do ambiente ODE, denominada ODEDoc. Esses requisitos foram adaptados e reformulados a partir dos requisitos de uma outra ferramenta de apoio à documentação, XMLDoc, desenvolvida em (SILVA, 2004) e (SOARES, 2002). Na seção 3.1 tratamos dos requisitos funcionais, ou seja, das necessidades do sistema. Na seção 3.2 são tratados os requisitos não-funcionais. 3.1 Requisitos Funcionais Em se tratando de requisitos funcionais, os modelos de casos de uso, juntamente com suas descrições, fornecem uma eficiente forma de modelar esses requisitos. Tais modelos dão ao desenvolvedor uma visão externa do problema a ser capturado, mostrando a interação entre o usuário e o sistema. Os casos de uso possuem dois importantes papéis (FALBO, 2000): Capturar os requisitos funcionais do sistema. Um modelo de caso de uso define o comportamento de um software (e a informação associada) através de um conjunto de casos de uso. O ambiente do sistema é definido pela descrição dos diferentes atores. Esses atores utilizam o sistema através de um número de casos de uso; Oferecer uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, é comum apresentar os modelos do sistema em um número de diferentes visões. Em uma abordagem guiada por casos de uso, pode-se construir uma visão para cada caso de uso, isto é, em cada visão são modelados apenas aqueles elementos que participam de um caso de uso específico. Isto 21

22 significa que um modelo de sistema completo só é visto através de um conjunto de visões. A Figura 3.1 mostra o diagrama de casos de uso para o desenvolvimento de ODEDoc. O ator Desenvolvedor pode criar um documento formatado e solicitar a geração dos documentos formatados do projeto. Os documentos formatados são gerados seguindo as instruções de modelos de documento, criados pelo Gerente de Documentação. Figura Diagrama de Casos de Uso. A seguir são apresentadas as descrições dos casos de uso Caso de Uso Editar Modelo de Documento Este caso de uso é realizado pelo gerente de documentação e é responsável por criar, alterar e excluir um modelo de documento. Os cenários Criar Modelo de Documento, Alterar Modelo de Documento e Excluir Modelo de Documento compõem este caso de uso. 22

23 Cursos Normais Criar Modelo de Documento O gerente de documentação informa o nome, uma descrição, o título, o corpo do preâmbulo e o tipo de artefato ao qual se aplica o modelo de documento. Caso os dados sejam válidos, um novo modelo de documento é criado. O cenário Criar Modelo de Seção do caso de uso Editar Modelo de Seção é chamado. Alterar Modelo de Documento O gerente de documentação informa o modelo de documento que deseja alterar e os novos dados. Caso os dados sejam válidos, a alteração é registrada. Cenários do caso de uso Editar Modelo de Seção podem ser chamados. Excluir Modelo de Documento O gerente de documentação informa o modelo de documento que deseja excluir. Uma confirmação para a operação é solicitada. Se a exclusão for confirmada, o modelo de documento e seus modelos de seção são excluídos. Não é permitida a exclusão de modelos de documento que possuam documentos formatados associados. Cursos Alternativos Criar/Alterar Modelo de Documento Dados inválidos: Uma mensagem de erro é exibida solicitando correção dos dados. Excluir Modelo de Documento Existe um ou mais documentos formatados associados ao modelo de documento: Uma mensagem de erro é exibida, informando ao gerente de documentação que existem documentos formatados associados ao modelo de documento e a exclusão não pode ser realizada. 23

24 3.1.2 Caso de Uso Editar Modelo de Seção Este caso de uso permite criar, alterar e excluir modelos de seção de um modelo de documento. Os cenários Criar Modelo de Seção, Alterar Modelo de Seção e Excluir Modelo de Seção compõem esse caso de uso. Cursos Normais Criar Modelo de Seção O gerente de documentação informa o modelo de seção pai, caso a seção a ser criada seja subseção de uma outra, o título, se a existência de seções desse tipo nos documentos a serem gerados é obrigatória ou opcional, o corpo de texto básico da seção e, opcionalmente, o tipo de artefato que deverá compor o corpo do modelo de seção. Caso os dados sejam válidos, um novo modelo de seção é criado. Caso o modelo de seção não tenha um modelo de seção pai, ele é adicionado como a última seção do modelo de documento. Caso contrário, a nova seção deve ser adicionada ao final da lista de subseções do modelo de seção pai do mesmo. Alterar Modelo de Seção O gerente de documentação informa o modelo de seção que deseja alterar e os novos dados. Caso os dados sejam válidos a alteração é registrada. Excluir Modelo de Seção O gerente de documentação informa o modelo de seção que deseja excluir. Os dados são apresentados e é solicitada uma confirmação. Se a exclusão for confirmada, o modelo de seção e todas as suas subseções são excluídos. Não é permitida a exclusão de um modelo de seção que tenha seções em documentos formatados associados. Cursos Alternativos Criar Modelo de Seção/Alterar Modelo de Seção Dados inválidos: Uma mensagem de erro é exibida solicitando a correção dos dados. 24

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

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 Software

Documento de Projeto de Software Documento de Projeto de Software Projeto: Vídeo Locadora Passatempo Versão: 1.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta o documento de projeto (design) do sistema de

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

Apoio à Gerência de Recursos em ODE

Apoio à Gerência de Recursos em ODE UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO ALEXANDRE GUILHERME NICCO COELHO Apoio à Gerência de Recursos em ODE Vitória 2007 1 ALEXANDRE GUILHERME NICCO

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

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

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com)

ARQUITETURA DE SISTEMAS. Cleviton Monteiro (cleviton@gmail.com) ARQUITETURA DE SISTEMAS Cleviton Monteiro (cleviton@gmail.com) Roteiro Definição Documento de arquitetura Modelos de representação da arquitetura Estilos arquiteturais Arquitetura de sistemas web Arquitetura

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

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

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

Engenharia de Software na Prática Hélio Engholm Jr.

Engenharia de Software na Prática Hélio Engholm Jr. Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional

Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento

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

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

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

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

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Prof. Elias Batista Ferreira Material cedido por: Prof. Edison A M Morais Objetivo Descrever os processos da norma

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Sistema Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert

Sistema Gerenciador de Hotel. Adriano Douglas Girardello. Ana Paula Fredrich. Tiago Alexandre Schulz Sippert UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Sistema Gerenciador de Hotel Adriano Douglas Girardello

Leia mais

Gerenciamento de Configuração de Software

Gerenciamento de Configuração de Software Gerenciamento de Configuração de Software Prof. Ricardo Argenton Ramos [Baseado na apresentação do prof. Masiero ICMC-USP] Contexto para Gerência de Configuração 2 Problema dos Dados Compartilhados Desenvolvedor

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

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0

VANT-EC-SAME. Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 VANT-EC-SAME Software de Suporte do VANT V-SUP Caso de Desenvolvimento Versão 1.0 Histórico da Revisão Data Versão Descrição Autor 17/0/07 1.0 Versão Inicial Douglas Moura Confidencial VANT-EC-SAME, 2007

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

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

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE

ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE ABORDAGEM DE FRAMEWORKS PARA JSF QUE AUXILIAM O DESENVOLVIMENTO DE SOFTWARE Amarildo Aparecido Ferreira Junior 1, Ricardo Ribeiro Rufino 1 ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil aapfjr@gmail.com

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

EVOLUÇÃO DE SOFTWARE

EVOLUÇÃO DE SOFTWARE EVOLUÇÃO DE SOFTWARE Dinâmica da evolução de programas Manutenção de software Processo de evolução Evolução de sistemas legados 1 Mudança de Software 2 Manutenção de software Mudança de software é inevitável

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

Leia mais

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 II

Engenharia de Software II Engenharia de Software II Aula 27 http://www.ic.uff.br/~bianca/engsoft2/ Aula 27-26/07/2006 1 Ementa Processos de desenvolvimento de software Estratégias e técnicas de teste de software Métricas para software

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

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião

AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE. Prof. Msc. Hélio Esperidião AULA 1 INTRODUÇÃO - ENGENHARIA DE SOFTWARE Prof. Msc. Hélio Esperidião O QUE É UM ALGORITMO? É qualquer procedimento computacional bem definido que informa algum valor ou conjunto de valores como entrada

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Figura 1 - Arquitetura multi-camadas do SIE

Figura 1 - Arquitetura multi-camadas do SIE Um estudo sobre os aspectos de desenvolvimento e distribuição do SIE Fernando Pires Barbosa¹, Equipe Técnica do SIE¹ ¹Centro de Processamento de Dados, Universidade Federal de Santa Maria fernando.barbosa@cpd.ufsm.br

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto

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

2 a Lista de Exercícios

2 a Lista de Exercícios Projeto de Sistemas 2011/2 2 a Lista de Exercícios (1) Um importante aspecto do projeto da camada de Lógica de Negócio (LN) diz respeito à organização das classes e distribuição de responsabilidades entre

Leia mais

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função

15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão

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

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

SISTEMA GERENCIAL TRATORPLAN

SISTEMA GERENCIAL TRATORPLAN SISTEMA GERENCIAL TRATORPLAN SIGET Fabrício Pereira Santana¹, Jaime William Dias¹, ², Ricardo de Melo Germano¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil fabricioblack@gmail.com germano@unipar.br

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

Leia 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

Anexo I Formulário para Proposta

Anexo I Formulário para Proposta PLATAFORMA CGI.br Solicitação de Propostas SP Anexo I Formulário para Proposta Data: 05/07/2013 Versão: 1.1 Plataforma CGI.br Solicitação de Propostas - SP Anexo I Formulário para Proposta 1. Estrutura

Leia mais

Requisitos de Software. Teresa Maciel DEINFO/UFRPE

Requisitos de Software. Teresa Maciel DEINFO/UFRPE Requisitos de Software Teresa Maciel DEINFO/UFRPE 1 Requisito de Software Características que o produto de software deverá apresentar para atender às necessidades e expectativas do cliente. 2 Requisito

Leia mais

NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE

NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE Marina Benedetti Preto¹ RESUMO Muito se fala sobre a qualidade de software, mas sem sempre se tem uma verdadeira noção deste conceito. A qualidade possui

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE

CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE CAPITULO 4 A ARQUITETURA LÓGICA PARA O AMBIENTE A proposta para o ambiente apresentada neste trabalho é baseada no conjunto de requisitos levantados no capítulo anterior. Este levantamento, sugere uma

Leia mais

Projeto: Simul-e Documento de Arquitetura de Software

Projeto: Simul-e Documento de Arquitetura de Software Projeto: Simul-e Documento de Arquitetura de Software Versão 1.0 Página 1 de 9 Histórico da Revisão Data Versão Descrição Autor 12.09.2015 1.0 Criação do Documento Hugo Pazolline 20.10.2015 1.0 Atualização

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS

UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS UM ESTUDO SOBRE ARQUITETURA PARA DESENVOLVIMENTO DE SOFTWARE WEB UTILIZANDO NOVAS TECNOLOGIAS Edi Carlos Siniciato ¹, William Magalhães¹ ¹ Universidade Paranaense (Unipar) Paranavaí PR Brasil edysiniciato@gmail.com,

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

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 03 In a calm sea every man is a pilot. Engenharia de Software I Aula 3 Gerenciamento de

Leia mais

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE

ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE ENGENHARIA DE SOFTWARE/ SISTEMAS DE SOFTWARE CMP1280/CMP1250 Prof. Me. Fábio Assunção Introdução à Engenharia de Software SOFTWARE Programa de computador acompanhado dos dados de documentação e configuração

Leia mais

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com

Engenharia de Software: conceitos e aplicações. Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com Engenharia de Software: conceitos e aplicações Prof. Tiago Eugenio de Melo, MSc tiagodemelo@gmail.com 1 Objetivos da aula Apresentar os conceitos de Engenharia de Software e explicar a sua importância.

Leia mais

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software

Análise e Projeto de Sistemas. Engenharia de Software. Análise e Projeto de Sistemas. Contextualização. Perspectiva Histórica. A Evolução do Software Análise e Projeto de Sistemas Análise e Projeto de Sistemas Contextualização ENGENHARIA DE SOFTWARE ANÁLISE E PROJETO DE SISTEMAS ENGENHARIA DA INFORMAÇÃO Perspectiva Histórica Engenharia de Software 1940:

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

UML - Unified Modeling Language

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

Leia mais

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás Prof.: Ivon Rodrigues Canedo PUC Goiás Qualidade Subjetiva Não sei o que é mas reconheço quando a vejo Qualidade Baseada no Produto O produto possui algo que produtos similares não têm Qualidade Baseada

Leia mais

Engenharia de Software

Engenharia de Software Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo

Leia mais

CAPÍTULO 35 Como utilizar os componentes ColdFusion

CAPÍTULO 35 Como utilizar os componentes ColdFusion CAPÍTULO 35 Como utilizar os componentes ColdFusion Os componentes ColdFusion (CFC) permitem ao usuário encapsular lógicas de aplicação e de negócios (business logic) em unidades auto-controladas reutilizáveis.

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

21. Qualidade de Produto ou Qualidade de Processo de Software?

21. Qualidade de Produto ou Qualidade de Processo de Software? 21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

Notas de Aula 05: Aplicação de um caso de uso

Notas de Aula 05: Aplicação de um caso de uso Notas de Aula 05: Aplicação de um caso de uso Objetivos da aula: Aprender a aplicar a técnica de casos de uso em um pequeno problema real Identificar as variáveis relevantes a serem consideradas Modelar

Leia mais

Atividade da gerência da qualidade

Atividade da gerência da qualidade O que é qualidade de software? Qualidade, de forma simplista, significa que o produto deve esta de acordo com a especificação. Problemas: Tensão entre requisitos do cliente: Eficiência, confiança, etc.

Leia mais

Qualidade de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Qualidade de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Qualidade do produto

Leia mais

FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES

FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES FERRAMENTA PARA CONSTRUÇÃO DE INTERFACES DE SOFTWARE A PARTIR DE DIAGRAMA DE CLASSES Aluno: André Luis Becker Orientador: Prof. Everaldo Artur Grahl. Mestre Orientador, FURB Roteiro da Apresentação Introdução;

Leia mais

Codificar Sistemas Tecnológicos

Codificar Sistemas Tecnológicos Codificar Sistemas Tecnológicos Especificação dos Requisitos do Software Sistema de gestão para a Empresa Cliente SlimSys Autor: Equipe Codificar Belo Horizonte MG Especificação dos Requisitos do Software

Leia mais

UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB

UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB UMA ABORDAGEM SOBRE OS PADRÕES DE QUALIDADE DE SOFTWARE COM ÊNFASE EM SISTEMAS PARA WEB Alan Francisco de Souza¹, Claudete Werner¹ ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil alanfsouza.afs@gmail.com,

Leia mais

4 O Workflow e a Máquina de Regras

4 O Workflow e a Máquina de Regras 4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES Alexandre Egleilton Araújo, Jaime Willian Dias Universidade Paranaense (Unipar) Paranavaí PR Brasil araujo.ale01@gmail.com, jaime@unipar.br Resumo.

Leia 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: 13B DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar, discutir o conceito de métricas de software orientadas a função. DESENVOLVIMENTO

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

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

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: davidmr@ifce.edu.br CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0 SUMÁRIO 1 Conceitos Básicos... 3 1.1 O que é Software?... 3 1.2 Situações Críticas no desenvolvimento

Leia 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

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos

Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos Sistema de Gestão dos Documentos da Engenharia [EDMS] O caminho para a Colaboração da Engenharia e Melhoria de Processos O gerenciamento de informações é crucial para o sucesso de qualquer organização.

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

Leia mais

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de

Atividades da Engenharia de Software GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE. Atividades da Engenharia de Software. Processo de Desenvolvimento de SCE186-ENGENHARIA DE SOFTWARE Módulo 1 Atividades da Engenharia de GERENCIAMENTO DA CONFIGURAÇÃO DE SOFTWARE Profª Rosely Sanches rsanches@icmc.usp.br 2003 DEFINIÇÃO CONSTRUÇÃO SOFTWARE PRODUTO MANUTENÇÃO

Leia mais

IC-UNICAMP IC-UNICAMP

IC-UNICAMP IC-UNICAMP Capítulo 3: Qualidade de Produto e a ISO 9126 Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6:

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

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental

Ciclo de Vida Clássico ou Convencional CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS. Ciclo de Vida Clássico ou Convencional. Enfoque Incremental CICLOS DE VIDA DE DESENVOLVIMENTO DE SISTEMAS Elicitação Ciclo de Vida Clássico ou Convencional O Modelo Cascata Análise Ana Paula Terra Bacelo Blois Implementação Material Adaptado do Prof. Marcelo Yamaguti

Leia mais

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:

Apesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma: 1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que

Leia mais

Manual SAGe Versão 1.2 (a partir da versão 12.08.01)

Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Manual SAGe Versão 1.2 (a partir da versão 12.08.01) Submissão de Relatórios Científicos Sumário Introdução... 2 Elaboração do Relatório Científico... 3 Submissão do Relatório Científico... 14 Operação

Leia mais