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

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

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

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

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

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

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

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

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

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

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

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

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

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

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

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

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

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

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

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

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

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software

ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software ControlPro: Uma Ferramenta de Acompanhamento de Projetos Integrada a um Ambiente de Desenvolvimento de Software Rodrigo Dal Moro, Julio Cesar Nardi, Ricardo de Almeida Falbo Departamento de Informática

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

Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD

Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD Apresentação TRIBUNAL SUPERIOR ELEITORAL SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO COORDENADORIA DE LOGÍSTICA SEÇÃO DE ADMINISTRAÇÃO DE DADOS E-mail: sead@tse.jus.br Nome do Projeto: Revisão do processo de

Leia mais

Tércio Oliveira de Almeida. TCC - Nexus - RAS

Tércio Oliveira de Almeida. TCC - Nexus - RAS Tércio Oliveira de Almeida TCC - Nexus - RAS Porto Alegre 12 de novembro de 2009 Tércio Oliveira de Almeida TCC - Nexus - RAS Trabalho de Graduação Orientador: Prof. Dr. Marcelo Soares Pimenta UNIVERSIDADE

Leia mais

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

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

Leia mais

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

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

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

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

Documentação de um Produto de Software

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

Leia mais

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

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

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

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

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

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

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

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

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

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

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

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

Estudo de Caso Sistema de Caixa Automático

Estudo de Caso Sistema de Caixa Automático Estudo de Caso Sistema de Caixa Automático Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Notas de Aula Ulrich Schiel Notas de Aula Ariadne

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

ESTUDO COMPARATIVO DE BIBLIOTECAS GRÁFICAS I TEGRADAS COM OPE GL

ESTUDO COMPARATIVO DE BIBLIOTECAS GRÁFICAS I TEGRADAS COM OPE GL ESTUDO COMPARATIVO DE BIBLIOTECAS GRÁFICAS I TEGRADAS COM OPE GL Francisco Tiago Avelar, Vitor Conrado F. Gomes, Cesar Tadeu Pozzer Universidade Federal de Santa Maria UFSM Curso de Ciência da Computação

Leia mais

Roteiro do Trabalho Prático

Roteiro do Trabalho Prático Projeto de Sistemas - 2011/2 Roteiro do Trabalho Prático O trabalho prático consta da realização das atividades de Projeto da Arquitetura de Software e Projeto dos Componentes da Arquitetura, devendo ser

Leia mais

Apoio Automatizado à Gerência de Projetos em ODE

Apoio Automatizado à Gerência de Projetos em ODE UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO LUCAS DE OLIVEIRA ARANTES Apoio Automatizado à Gerência de Projetos em ODE Vitória 2006 LUCAS DE OLIVEIRA ARANTES

Leia mais

Engenharia de Software

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

Leia mais

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

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

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

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

GERÊNCIA DE CONHECIMENTO APLICADA A DESENVOLVIMENTO ÁGIL DE SOFTWARE COM SCRUM.

GERÊNCIA DE CONHECIMENTO APLICADA A DESENVOLVIMENTO ÁGIL DE SOFTWARE COM SCRUM. UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA ROGNER RANGEL AHNERT GERÊNCIA DE CONHECIMENTO APLICADA A DESENVOLVIMENTO ÁGIL DE SOFTWARE COM SCRUM. VITÓRIA 2014 ROGNER

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

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

Leia mais

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

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

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

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

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

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

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

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

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

Leia mais

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código

GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código GeCA: Uma Ferramenta de Engenharia Reversa e Geração Automática de Código Igor Steinmacher 1, Éderson Fernando Amorim 1, Flávio Luiz Schiavoni 1, Elisa Hatsue Moriya Huzita 1 1 Departamento de Informática

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

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

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

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Leia mais

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor

Agenda da Aula. Resumo dos Padrões (Aula 4) Padrões Arquiteturais. Arquitetura Cliente-Servidor. Arquitetura Cliente-Servidor Reuso de Software Aula 05 Agenda da Aula Linha de Produtos de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo reuso.software@gmail.com 19 Março 2012 Padrões arquiteturais Cliente-Servidor

Leia mais

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi

Gerenciador Financeiro CITi. Gerenciador Financeiro CITi (Sistema de Gerenciamento Financeiro) Especificação dos Requisitos do Software Gerenciador Financeiro CITi Versão 1.0 Autores: Bruno Medeiros de Oliveira Igor Rafael Medeiros Pedro Araújo de Melo Tiago

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

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

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso...

4. Exemplo de Levantamento de Classes...26. 3. Levantamento das Classes...24. 1. Conceito de Classe e Objeto... 15. 1. Modelo de Casos de Uso... Projeto de Software usando UML Sumário Capítulo I : Casos de Uso...3 1. Modelo de Casos de Uso... 3 2. Diagramas de Casos de Uso... 3 3. Exemplo... 9 4. Conclusão... 13 Capítulo II : Levantamento de Classes...15

Leia mais

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

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

Leia mais

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

Documento de Visão do Projeto

Documento de Visão do Projeto Documento de Visão do Projeto 1. Objetivo O propósito deste documento é coletar, analisar e definir as necessidades de alto-nível e características do projeto de software do Módulo Editor de Estruturas

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

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo

Plano de Projeto. 1. Introdução. 2. Escopo do Projeto. Projeto: Biblioteca Central da UFES. Versão: 2.0. Responsável: Ricardo de Almeida Falbo Plano de Projeto Projeto: Biblioteca Central da UFES Versão: 2.0 Responsável: Ricardo de Almeida Falbo 1. Introdução Este documento apresenta a versão 2.0 do Plano de Projeto para o projeto de desenvolvimento

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

Modelos de Qualidade de Produto de Software

Modelos de Qualidade de Produto de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Modelos de Qualidade de Produto de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

6 Infraestrutura de Trabalho

6 Infraestrutura de Trabalho 6 Infraestrutura de Trabalho Este capítulo tem como objetivo fornecer uma visão geral do ambiente de trabalho encontrado na organização estudada, bem como confrontá-lo com a organização ideal tal como

Leia mais

Unioeste Universidade Estadual do Oeste do Paraná

Unioeste Universidade Estadual do Oeste do Paraná 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 Especificação de Requisitos e Modelagem Orientada

Leia mais

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP

Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP UNIVERSIDADE DE SÃO PAULO Instituto de Ciências Matemáticas e de Computação Departamento de Ciências da Computação e Estatística Documentação do Sistema de Reserva de Salas da Intranet do ICMC-USP André

Leia mais

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios

Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas. Criação de uma Serviço de Geração de Relatórios Universidade Federal de Goiás Centro de Recursos Computacionais - CERCOMP Divisão de Sistemas Criação de uma Serviço de Geração de Relatórios Goiânia 12/2011 Versionamento 12/12/2011 Hugo Marciano... 1.0

Leia mais

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias

CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias CURSO DESENVOLVEDOR JAVA Edição Intensiva de Férias O curso foi especialmente planejado para os profissionais que desejam trabalhar com desenvolvimento de sistemas seguindo o paradigma Orientado a Objetos

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

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

Documento de Requisitos

Documento de Requisitos Documento de Requisitos Projeto: Data 26/05/2005 Responsável Autor (s) Doc ID Localização Versão do Template Márcia Jacyntha Nunes Rodrigues Lucena Silvia Cássia Pereira Márcia Jacyntha Nunes Rodrigues

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

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

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

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

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

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes.

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

DESAFIO ETAPA 1 Passo 1

DESAFIO ETAPA 1 Passo 1 DESAFIO Um dos maiores avanços percebidos pela área de qualidade de software foi comprovar que a qualidade de um produto final (software) é uma consequência do processo pelo qual esse software foi desenvolvido.

Leia mais

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software Prof. Dr. Juliano Lopes de Oliveira (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

Leia mais