EXPERIÊNCIA NA CUSTOMIZAÇÃO DE UM MODELO DE PROCESSO DE SOFTWARE PARA DESENVOLVIMENTO DE APLICATIVO PARA WEB UTILIZANDO OO



Documentos relacionados
Aplicação de Extensões UML no Modelo Navegacional em um processo customizado para sistemas para World Wide Web

3 Um Framework Orientado a Aspectos para Monitoramento e Análise de Processos de Negócio

UML - Unified Modeling Language

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

Engenharia de Requisitos Estudo de Caso

O modelo unificado de processo. O Rational Unified Process, RUP.

3. Fase de Planejamento dos Ciclos de Construção do Software

2 Diagrama de Caso de Uso

Sistemas para internet e software livre

APLICAÇÃO DE EXTENSÕES UML NO MODELO NAVE- GACIONAL EM UM PROCESSO CUSTOMIZADO PARA SISTEMAS PARA WORLD WIDE WEB

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite (81 )

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

Modelagemde Software Orientadaa Objetos com UML

Fase 1: Engenharia de Produto

Introdução ao RUP Rational Unified Process. por Denize Terra Pimenta Outubro/2004

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

IMPLANTAÇÃO DE UM SISTEMA DE AVALIAÇÃO DE DESEMPENHO NA UFG

Engenharia de Software I

Desenvolvendo uma Arquitetura de Componentes Orientada a Serviço SCA

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

Orientação a Objetos

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

Feature-Driven Development

DESENVOLVENDO APLICAÇÃO UTILIZANDO JAVA SERVER FACES

DESENVOLVIMENTO DE INTERFACE WEB MULTIUSUÁRIO PARA SISTEMA DE GERAÇÃO AUTOMÁTICA DE QUADROS DE HORÁRIOS ESCOLARES. Trabalho de Graduação

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

TI Aplicada. Aula 02 Áreas e Profissionais de TI. Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com

Introdução a INGENIAS:

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

Metodologia e Gerenciamento do Projeto na Fábrica de Software

Modelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.

A Linguagem de Modelagem Unificada (UML)

O Rational Unified Process (RUP) é um processo de desenvolvimento de software inspirado no

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

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Desenvolvimento de um CMS 1 para a criação e publicação de web sites acessíveis por deficientes visuais.

Documento de Arquitetura

O Processo Unificado: Captura de requisitos

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

Concepção e Elaboração

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

Introdução a Computação

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

Processos de Desenvolvimento de Software

Modelagem de Casos de Uso (Parte 1)

PROJETO DE FÁBRICA DE SOFTWARE

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

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

Diagrama de Caso de Uso e Diagrama de Sequência

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix.

Rock In Rio - Lisboa

RUP. Evolução. Principais Características do RUP. Principais Características do RUP RUP

2 Geração Dinâmica de Conteúdo e Templates de Composição

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

Estrutura do Trabalho: Fazer um resumo descrevendo o que será visto em cada capítulo do trabalho.

Sumário. Uma visão mais clara da UML

ENGENHARIA DE SOFTWARE I

Unified Process. Sueleni Mendez Batista. Orientadora: Dra. Elisa Hatsue Moriya Huzita

Geração do Portal CPCX - UFMS pelo UNION: Um Estudo de Caso

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

Introdução à Engenharia de Software

Processo de Desenvolvimento Unificado

Documento de Requisitos

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

ANÁLISE E PROJETO ORIENTADO A OBJETOS. Isac Aguiar isacaguiar.com.br isacaguiar@gmail.com

Projeto de Sistemas I

Autoria:Aristófanes Corrêa Silva Adaptação: Alexandre César M de Oliveira

O Processo Unificado

Documento de Análise e Projeto VideoSystem

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Processos de Desenvolvimento de Software. Prof. Hélio Engholm Jr

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

Ricardo Roberto de Lima UNIPÊ APS-I. Históricos e Modelagem Orientada a Objetos

AUTOR: DAVID DE MIRANDA RODRIGUES CONTATO: CURSO FIC DE PROGRAMADOR WEB VERSÃO: 1.0

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

PRINCÍPIOS DE SISTEMAS DE INFORMAÇÃO MÓDULO 17

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

1

FACULDADE DE ENGENHARIA DE COMPUTAÇÃO. PROJETO FINAL I e II PLANO DE TRABALHO <NOME DO TRABALHO> <Nome do Aluno> <Nome do Orientador>

Procedimentos Operacionais (POs)

Engenharia de Software III

Projeto Pé na Dança. Bruno Barros Comunicador Visual /

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS

Modelagem OO com UML. Vítor E. Silva Souza ~ vitorsouza

3 OOHDM e SHDM 3.1. OOHDM

GESTÃO DAS INFORMAÇÕES DAS ORGANIZAÇÕES MÓDULO 11

Metodologia de Desenvolvimento de Software. Prof. M.Sc. Sílvio Bacalá Jr

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

Análise e Projeto Orientados por Objetos

Sistemas de Informação I

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

Engenharia de Domínio baseada na Reengenharia de Sistemas Legados

PROFESSOR: CRISTIANO MARIOTTI

Wilson Moraes Góes. Novatec

A Disciplina Gerência de Projetos

Transcrição:

Conferência IADIS Ibero-Americana WWW/Internet 2007 EXPERIÊNCIA NA CUSTOMIZAÇÃO DE UM MODELO DE PROCESSO DE SOFTWARE PARA DESENVOLVIMENTO DE APLICATIVO PARA WEB UTILIZANDO OO Marla Teresinha Barbosa Geller 1 e Rodrigo Quites Reis 2 1 Programa de Pós-Graduação em Engenharia Elétrica Universidade Federal do Pará - Brasil 2 Programa de Pós-Graduação em Engenharia Elétrica Universidade Federal do Pará Brasil 2 Programa de Pós-Graduação em Ciências da Computação Universidade Federal do Pará - Brasil RESUMO Este trabalho apresenta o relato de uma experiência com a customização de modelo de processo de software para sistemas baseados na Web, a partir da adaptação e combinação de modelos existentes. Para ilustrar o trabalho, o modelo de processo é instanciado guiando o desenvolvimento do projeto de um portal Web para atender empresas do ramo imobiliário que oferecem seus produtos (imóveis) via Internet. O modelo de processo proposto utiliza tecnologia Orientada a Objetos, enquanto que o estudo de caso o aplica na condução do uso com um conjunto de ferramentas de software de apoio (Banco de dados Caché para o armazenamento, Dreamweaver para criação das páginas, e a ferramenta CASE Rational Rose para modelagem). PALAVRAS CHAVE Desenvolvimento de Sistemas Web, Customização de Processos, Modelagem Navegacional, Extensões UML. 1. INTRODUÇÃO A evolução no desenvolvimento de produtos e serviços no setor de Tecnologia da Informação implica em uma crescente preocupação com a qualidade do trabalho e tecnologia desenvolvidos. No que diz respeito ao desenvolvimento de software de qualidade, há grande demanda de trabalhos que auxiliem na definição e melhoria dos processos usados pelas organizações. Mais recentemente, a Engenharia de Processos de Software surgiu como uma área multidisciplinar, envolvendo questões técnicas, administrativas e metodológicas na concepção, adaptação e instanciação de processos de software para diferentes contextos e organizações. Por sua vez, a utilização da Internet como meio de disponibilização de serviços cresce incessantemente e a demanda por sistemas cada vez mais complexos e especializados baseados na World Wide Web tornou-se preocupação relevante para a Engenharia de Software. A definição de processos para guiar o desenvolvimento de software para a Web é um trabalho atual que lida com desafios adicionais por se tratar de um tema dinâmico e cuja experiência freqüentemente não é descrita com grande detalhe. Assim, o trabalho de conceber um novo modelo de processo de software ou adaptar um existente para este contexto deve considerar as características específicas dos sistemas e seus ambientes operacionais, os cenários e multiplicidade de perfis de usuários, e o tipo, experiência e conhecimento das pessoas envolvidas no processo de desenvolvimento [12]. Um grande número de projetos objetiva descrever modelos de processo para orientar aplicações Web, podendo-se citar: HDM (Hypermedia Design Model) [6], OOHDM (Object Oriented Hypertext Design Model) [11], UPHD (Hypermedia Systems Development base on the Unified Process) [8], WebPraxis [1], WebML (Web Modeling Language) [3], entre outros. Grande parte das propostas é baseada em adaptações do Unified Process (UP) [12], utilizando como ponto de partida a Web Application Extension (WAE) [4]. 145

ISBN: 978 972 8924 45-4 2007 IADIS Com base no exposto acima, este trabalho tem como objetivo propor um modelo de processo de software desenvolvido a partir de adaptações de modelos existentes, tendo como opção norteadora o uso do paradigma de Orientação a Objetos em todas as fases relacionadas com a arquitetura do software. Deve-se observar, entretanto, que a proposta aqui apresentada é um esforço inicial neste tema que não tem a pretensão de se tornar uma referência balizadora para todos os trabalhos na área. Ao contrário, é objetivo estabelecer uma condição de contorno específica onde os resultados da experiência podem ser avaliados, enriquecendo a discussão sobre a influência do processo na qualidade do software. O trabalho está organizado como segue. A seção 2 apresenta considerações gerais sobre o sistema. A seção 3 descreve o modelo de processo proposto. A seção 4 apresenta uma análise do modelo e contribuições. Na última seção, são apresentadas as considerações finais e sugestões para trabalhos futuros. 2. CONSIDERAÇÕES SOBRE O SISTEMA Nessa seção são feitas algumas considerações sobre o projeto idealizado para melhor contextualização de todo o trabalho e determinação dos seus objetivos. O estudo de caso proposto para ilustração do trabalho é a criação de um Portal de Imóveis de Santarém (PA), que atende um grupo de empresas imobiliárias instaladas na cidade. O sistema disponibiliza via Web serviços de atendimento aos clientes, que podem visualizar os imóveis através de imagens e obter informações detalhadas como localização, preço, descrição, entre outros. Este trabalho visa demonstrar a utilização do Unified Process com algumas adaptações para aplicações Web. Como proposta de adaptações segue-se o método UPHD proposto por Nora Koch[8][9] e também o método WAE que é a proposta de Conallen [4] para desenvolvimento Web. O estudo de processos para aplicações Web a partir de processos já existentes identifica que as fases que os diferenciam mais significativamente são as fases de análise e projeto [2], sendo desta forma as fases mais detalhadas nesse trabalho. O paradigma da Orientação a Objetos é utilizado desde a Análise de Requisitos ao Armazenamento dos Dados - obtido com um SGBDOO dessa forma o trabalho evolui em torno desta condição de homogeneidade. Assim, esta é uma característica importante de diferenciação deste trabalho, pois apresenta uma experiência prática que utiliza um modelo de Banco de Dados Orientado a Objetos no processo de software. 3. MODELO DE PROCESSO ADOTADO Essa seção contém a descrição do processo proposto. Este modelo foi concebido a partir da espinha dorsal do Unified Process, dividindo-se em quatro fases principais, a saber: Concepção, Elaboração, Construção e Transição[12]. O material aqui apresentado tem seu enfoque principal nas fases de Concepção e Elaboração, com os fluxos de trabalho (workflows) mais significativos para cada fase sendo especificados através dos operadores (neste caso o analista desenvolvedor e o projetista web), atividades e artefatos (especificados na figura 1). Através do Diagrama de Atividades apresentado na figura 1, tem-se uma visão do fluxo de controle da proposta de modelo de processo de desenvolvimento. A notação agrupa as atividades em iterações e fasespadrão. Os artefatos produzidos por cada workflow são representados como objetos. Nesta proposta, a Fase de Concepção é realizada em duas iterações. A primeira iteração inclui as atividades de identificar os usuários do sistema, elucidar informações e a navegação necessária, identificar atores e casos de uso e definir vocabulário comum. Na segunda iteração, os casos de uso são refinados e priorizados e as necessidades para as interfaces dos usuários são definidas. A Fase de Elaboração é realizada em (pelo menos 1 ) três iterações, sendo que na primeira iteração é feita uma análise dos casos de uso priorizados. O projeto conceitual, a definição da arquitetura, o projeto navegacional e o projeto de apresentação finalizam essa iteração. A segunda iteração inclui o modelo 1 Um número maior de iterações é possível quando houver necessidade de tratar alguns elementos com um maior nível de detalhe ainda dentro da mesma fase. 146

Conferência IADIS Ibero-Americana WWW/Internet 2007 temporal e o detalhamento das classes. A terceira iteração dessa fase faz o modelo de implementação através da identificação dos componentes necessários. O conteúdo das páginas do website é especificado e a estrutura do hiperespaço é definida também nessa iteração. A atualização do modelo, a implementação das interfaces e um planejamento para a Fase de Construção finalizam a Fase de Elaboração. 4. ANÁLISE DO PROCESSO E PROPOSTAS PARA CUSTOMIZAÇÃO Esta seção apresenta uma Análise do Processo e faz sugestão para adaptá-lo conforme as necessidades do sistema desenvolvido. 4.1 Análise dos Processos - Base Após estudos feitos para conhecimento de alguns processos existentes que tratam das especificidades para desenvolvimento de aplicações Web, fez-se a opção pelo processo proposto por Nora Koch [8] com a utilização de recursos da WAE, proposta por Conallen [4]. Tal escolha se deve ao fato de que UPHD e WAE possuem algumas similaridades e diversidades, mas ao mesmo tempo são complementares. Ambos descrevem um processo para desenvolvimento de aplicações Web utilizando extensões UML para modelagem. O WAE é baseado no RUP e descreve o processo através de modelos enquanto que o UPHD utiliza as fases do UP mostrando como as atividades de cada workflow podem ser modeladas através de extensões UML. A complementaridade dos dois métodos acentua-se pelo fato de que o UPHD atende aos aspectos de navegação e de apresentação de aplicações Web não atendidas pelo método WAE. Por outro lado o método WAE define estereótipos para aspectos relevantes não encontrados no UPHD, como páginas Web. Os dois processos utilizados como base fazem a especificação de detalhes para modelar sistemas direcionados para Web. Os recursos de modelagem sugeridos pelo UPHD são em alguns casos detalhados minuciosamente, o que pode ocasionar um bom resultado se a interpretação for também cuidadosa. Por outro lado exige uma atenção e rigidez na interpretação dos modelos que pode desestimular o desenvolvedor. Como exemplo, pode-se verificar os Modelos de Apresentação Estático e Dinâmico sugeridos que incluem muitos estereótipos semelhantes. Uma diferença estrutural entre os dois processos é evidenciada no modelo navegacional. No UPHD, KOCH refere-se ao modelo navegacional de classes e modelo de estrutura navegacional como sendo parte do projeto navegacional no workflow de Análise e Projeto. No WAE, Conallen, acrescenta o modelo de experiência do Usuário (ou modelo UX) que especifica características das telas na visão do usuário, bem como a navegação entre as classes. Conallen criou um conjunto de estereótipos para esse modelo, bastante sugestivo. O detalhamento minucioso das atividades e artefatos produzidos por cada workflow que são sugeridos pelo UPHD [8] facilita sobremaneira o desenvolvimento do trabalho. Porém, a descrição do método UPHD quando utiliza os três workflows principais Levantamento de requisitos, Análise e Projeto e Implementação sem mencionar as fases, dificulta a divisão de tarefas de cada fase e a definição do nível de abstração, principalmente quando é referido o workflow de Implementação onde Elaboração e Construção estão sem uma linha definida. As extensões propostas pelos dois métodos para expressar um projeto de aplicação Web têm como ponto positivo a integração entre os elementos específicos para Web e o restante dos elementos do sistema. 147

ISBN: 978 972 8924 45-4 2007 IADIS Concepção(1a. iteração) Concepção(2a. Iteração) Elaboração (1a. Iteração) Elaboração (2a. Iteração) Elaboração (3a. Iteração) 1a. iteração da Fase de Concepção, workf low de Levantamento de Requisitos 2a. iteração da Fase de Concepção, workf low de Levantamento de Requisitos 1a. iteração da Fase de Elaboração, workf low de Análise e Projeto 2a. iteração da Fase de Elaboração, workf low de Análise e Projeto 3a. iteração da Fase de Elaboração, worlf low de implementação Perfil do Usuário Identificar Usuários Descrição do Conteúdo Modelo de CSU detalhado Refinar Casos de uso Análise dos Casos de uso Diagramas de Seqüência Projeto Conceitual e Def inição da Arquitetura Identif icar Componentes Prover o Conteúdo Modelo de Componentes Conteúdo Elucidar Inf ormações Necessárias Def inição da arquitetura Modelo Conceitual Modelo Temporal Implementar estrutura do Hiperespaço Classes Persistentes Cenários Elucidar Navegação necessária Priorizar Casos de Uso Projeto Navegacional Modelo Navegacional Detalhamento das Classes Atualizar o Modelo Links Principis Modelo Atualizado Modelo de Casos de Uso Descrição das Interfaces Projeto de Apresentação Classes Detalhadas Implementar Interfaces Protótipo de Interfaces Encontrar atores e Casos de Uso Glossário Def inir necessidades para Interf aces Modelo de Apresentação Planejamento para Fase de Construção Plano de Atividade para Construção Levantamento do vocabulário Figura 1. Fluxo de controle das atividades do processo de desenvolvimento proposto Fase de Concepção e de Elaboração. 4.2 Proposta de customização Algumas experiências têm sido descritas [5] [7] para sugerir estratégias e regras que devem ser seguidas para customização de processos. Das observações importantes pode-se realçar como preocupação comum o fato de que para o sucesso de uma customização é necessário conhecimento sólido do processo escolhido como base e cuidadosa análise do problema para o qual deve ser desenvolvido o sistema. Após estudo dos processos de Conallen [4] e Koch [8] e com alguma experiência no problema envolvido o resultado da aplicação do processo com as adaptações necessárias é descrito a seguir. A proposta sugerida é baseada na característica de complementaridade entre os dois processos base. Assim, utilizam-se para modelar os aspectos navegacionais do sistema, os recursos do UPHD e para detalhar elementos que caracterizam sistemas Web, como páginas, formulários, quadros, utiliza-se o método de Conallen (WAE). Esse é um ponto importante da customização que faz com que as deficiências de um processo sejam supridas pelo outro. O processo UPHD sugere a participação de diferentes operadores como arquiteto, analista de hipermídia, engenheiro de hipermídia, projetista de interfaces, entre outros, para cumprir as atividades. Em um projeto de pequeno porte como o que é apresentado neste trabalho essas atividades são realizadas por dois operadores: o analista-desenvolvedor e o projetista web (web designer). No processo utilizado para o presente trabalho faz-se uma adaptação para separar as atividades do workflow de Implementação devido à dificuldade já descrita. As atividades do workflow de Implementação foram separadas para atividades na fase de Elaboração que consta basicamente do modelo de implementação, definição do conteúdo, inclusão dos principais links, construção das classes persistentes e esboço das interfaces principais do usuário. As atividades que constituem a Fase de Construção foram mencionadas em um Plano de Construção para trabalhos futuros. É importante que pontos de variabilidade do processo sejam explicitados dando origem, no trabalho aqui apresentado, em um tabela descritiva desses pontos, dos quais pode-se ressaltar: o número de iterações em cada workflow que podem se adequar ao tamanho e complexidade do projeto; em sistemas maiores também podem ser definidas atividades específicas para outros tipos de operadores como o arquiteto, analista de 148

Conferência IADIS Ibero-Americana WWW/Internet 2007 hipermídia, projetista de interface entre outros; em projetos maiores o Modelo Navegacional utilizado pode ser dividido em classes de persistência, controle e domínio evitando a sobrecarga no modelo; entre outros. Observa-se também que o estudo aqui apresentado, não inclui atividades importantes para projetos de sistemas Web, como o levantamento de requisitos não funcionais, citando entre os principais a Escalabilidade, a Heterogeneidade e a Segurança. Essa questão deve ser tratada na fase de Concepção e não pode ser capturada através de modelos, dessa forma deve ser apresentada através de uma lista textual. Tendo como principal objetivo a customização de um processo, tratando principalmente da adaptação de modelos, esse trabalho não inclui a definição dos requisitos não funcionais através de texto. A utilização da Orientação a Objetos em todo o desenvolvimento em especial no processo de armazenamento, é também parte da experiência de adaptação de novas tecnologias de implementação com o processo e constatação das facilidades/dificuldades dessa tecnologia. 4.3 Exemplo de Artefatos Produzidos Para o Portal de Imóveis de Santarém Como complemento do trabalho faz-se uma apresentação de alguns artefatos produzidos através do processo proposto. 4.3.1 Casos de Uso Considerado o artefato mais importante no levantamento dos requisitos, o Modelo de Casos de Uso é responsável por apresentar as funções pretendidas pelo sistema. Os aspectos dinâmicos e estáticos modelados posteriormente serão também orientados pelos casos de uso. Com base na análise do sistema estudado são identificados três atores administrador, usuário da imobiliária e cliente - porém para simplificação dos exemplos é feita a análise dos casos de uso para o ator usuário da imobiliária. Manter Regras Locação <<include>> Usuario Imobiliaria Manter Imoveis <<include>> Validar acesso <<include>> Consultar Imobiliaria 4.3.2 Modelo Conceitual Figura 2. Modelo de casos de uso Esse modelo constrói a estrutura das classes com os objetos envolvidos na interação entre usuários e a aplicação. Os principais elementos de modelo utilizados no modelo conceitual são as classes, as associações e os pacotes. O modelo da figura três traz o conjunto de classes que dão suporte ao sistema do Portal de Imóveis de Santarém 149

ISBN: 978 972 8924 45-4 2007 IADIS Administrador LoginAdm : %String = "" SenhaAdm : %String = "" RegraLocacao Clausula : %Stream = "" ListaDoc : %String = "" Obs : %String = "" Fone CodArea : %Integer Numero : %Integer Email Endereco : %String Oferta FimAcordo : %Date = "" InicioAcordo : %Date = "" 0..1 faz referência a Imovel Descricao : %String = "" Dorm : %Integer = "" Tipo : %String = "" Estado : %Boolean Disponibilidade : %String Preco : %Float 1..* 0..* pertence possui possui utiliza Imobiliaria Cnpj : %Integer = "" Creci : %String = "" NomeFantasia : %String = "" RazaoSocial : %String = "" Estado : %Boolean Endereco Bairro : %String = "" Cep : %String = "" Cidade : %String = "" Complemento : %String = "" Logradouro : %String = "" Num : %Integer = "" Uf : %String = "" 0..* Conteudo Titulo : %String dispõe possui 1..* 1..* Contato (from I... 1..* possui Atendente TipoAtendente : %String Horario : %String NomeAtendente : %String Usuario LoginUsuario : %String SenhaUsuario : %String Habilitado : %Boolean Video Video : %Stream Foto Foto : %Stream 4.3.3 Modelo Navegacional Figura 3. Modelo conceitual para o Portal de Imóveis de Santarém Representar a navegabilidade de um sistema baseado na Web é objetivo primordial desse modelo. Para representar as classes navegacionais de uma aplicação Web, é mostrado no quadro 1 abaixo os principais estereótipos da extensão UML propostos por Conallen[5] e utilizados no formato ícone de decoração nesse modelo. Para melhor entendimento do modelo navegacional, o diagrama é apresentado conforme as funcionalidades dos casos de uso identificados na seção 4.3.1 que são Manter Imóveis, Manter Regras para Locação e Consultar Imobiliária. A navegação entre as classes é através dos mecanismos como build (quando uma classe construtora dá origem à uma página- classe cliente), include (uma classes construtora usa outra classe do servidor), submit (quando em uma classe construtora, há um formulário que deve ser submetido ao servidor) e link (representa as ligações entre as páginas do servidor com a página cliente ou vice-versa). Ícone de decoração Pagina de serv idor Tabela 1: Estereótipos de classes utilizadas no modelo navegacional Descrição Representa uma página Web dinâmica que contém o conteúdo no servidor sempre que é solicitado. Interage com o banco de dados, lógica do negócio, sistemas externos através de scripts executados no servidor. Pagina do cliente São páginas Web formatadas em HTML, apresentadas pelos navegadores de clientes. Podem conter scripts que sejam interpretados pelo navegador. Formulario Um formulário é uma coleção de campos de entrada que fazem parte de uma página de cliente. Um formulário não possui operações, quaisquer operações que interajam com o formulário, serão propriedades da página cliente que o contém. 150

Conferência IADIS Ibero-Americana WWW/Internet 2007 <<Link>> Index.csp PaginaAbertura Imobiliaria.csp <<include>> Imovel.csp ValidarAcesso Regraslocacao.csp <<Link>> <<Link>> PaginaImoveis PaginaImobiliaria PaginaRegLocacao <<Link>> Imoveis_form DadosImobiliaria.csp RegrasLocacao_form <<Submit>> <<Submit>> ManterImovel ManterRegrasLoc PaginaDadosImob Imovel.cls ListaDeImoveis ResultManterRegLoc RegrasLocacao.cls As classes com extensão cl s são classes persistentes do banco de dados Caché Figura 4. Modelo navegacional para os casos de uso identificados na seção 4.3.1 5. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS A certeza de que o projeto para desenvolvimento de sistemas computacionais necessita de um Processo de Software é unanimidade entre os desenvolvedores, porém a prática do uso desses processos causa preocupações e críticas. A analogia feita por Osterweil em [10] de que Processo de software é também software, aproxima a teoria de processos e a prática, entendendo que a adoção de um processo no desenvolvimento de um sistema deve ser facilitada com recursos de modelagem e ferramentas apropriadas, resultando em melhor qualidade do software. A proposta aqui apresentada para utilização de processos já existentes como base para desenvolvimento de uma aplicação Web é resultado da constatação de que esses sistemas necessitam de recursos para especificar características particulares. No entanto, não se pode afirmar que esses sistemas devam ser considerados acentuadamente diferentes dos sistemas tradicionais. Para ambos a escolha de um processo adequado é extremamente importante, e a adaptação principalmente nas fases de Análise e Projeto do processo para especificar características de um sistema Web já é objeto de estudo e conclusões bastante definidas. O que se pode constatar é que adaptações são necessárias em todo processo de desenvolvimento, por mais definido e especificado que seja o processo, há sempre a subjetividade do próprio sistema, da interpretação do desenvolvedor, e das características da organização. A constatação da necessidade de explicitar os pontos de variabilidade do processo customizado tem origem nessas características, colocando essa contribuição como tema de discussão para melhoria da qualidade do processo. Como contribuição da experiência relatada pode-se citar: O processo resultante contribui com a prática da customização de processos, utilizando de forma inédita, a complementaridade entre o UPHD e WAE; construção de uma tabela relacionando os pontos de variabilidade do processo para torná-lo flexível, estimulando o desenvolvedor à pratica da adaptação sem descaracterizar o processo; processo resultante extremamente detalhado com fases e fluxos bem definidos; utilização de extensões UML na modelagem para sistemas Web contemplando as características específicas desses sistemas; fases críticas para sistemas Web são Concepção e Elaboração, portando as mais detalhadas no processo proposto; requisitos não funcionais não incluídos na análise, constituindo um ponto a ser discutido no workflow de Análise e Projeto da Fase de Construção; facilidade na criação das classes com o SGGBDOO, partindo dos modelos, não necessitando mapeá-las em tabelas. 151

ISBN: 978 972 8924 45-4 2007 IADIS Para avaliação do processo proposto, um sistema real foi modelado e como conseqüência obteve-se um protótipo do Portal de Imóveis de Santarém. O estudo de caso completo (disponível em http://labes.ufpa.br/marla/estudo) é um experimento de pequeno porte que valida alguns dos elementos do processo proposto. Observa-se, porém, que o enfoque do artigo (e do projeto de pesquisa associado) é a descrição da experiência com a customização do processo instanciado para o sistema proposto. A análise das características e dos atributos do software produzido é relevante como resultado final, porém não é descrita no presente trabalho por não fazer parte de seu escopo. A seqüência do trabalho seguindo o planejamento para a Fase de Construção, apresentado como último artefato no workflow de implementação, é objetivo de trabalhos futuros, bem como a aplicação do processo em sistemas para Web com variação significativa no escopo e complexidade. REFERÊNCIAS BIBLIOGRÁFICAS ALVARES, P. 2001. WebPraxis Um processo personalizado para projetos de desenvolvimento para Web. Dissertação de Mestrado, UFMG. ARAÚJO, A. 2001. Framework de Análise e Projeto Baseado no RUP para o Desenvolvimento de Aplicações WEB. Dissertação de Mestrado, UFPE, Centro de informática. CERI, S., FRATERNALI, P. BONGIO, A. 2005. Web Modeling Language (WebML): a modeling language for designing Web sites. Disponível em http://www9.org/w9cdrom/177/177.html. Acessado em outubro de 2005. CONALLEN, J. 2003 Desenvolvendo Aplicações Web com UML. Rio de Janeiro: Campus, 2003. FITZGERALD, B., RUSSO, N., O KANE, T. 2004. Software Development Method Tailoring at Motorola. Comunications of de ACM. Vol. 46, (Abril 2004) No. 4. GARZOTTO, F.; PAOLINI, P.; SCHWABE, D. 1993. HDM A Model-based Approach to Hypertext Application Design. TOIS 11(1), pp1-26. KENAN, F. 2004. Agile Process Tailoring and Problem Analysis. In Proceedings of 26 th International Conference on Software Engeneering (ICSE 04). KOCH, N. 2000. Hypermedia Systems Development based on the Unified Process. Technical Report 0003, Ludwig- Maximilians Universitty Munich. KOCH, N.; KRAUS, A. 2005. The Expressive Power of UML based Web Engineering. Disponível em: http://www.pst.informatik.uni-muenchen.de/personen/kochn. Acesso em outubro de 2005. OSTERWEIL, L. 1997. Software Process Are Software Too, Revisited. An Invited Talk on the Most Influential Paper of ICSE 9. University of Massachusetts. Boston, USA.. SCHWABE, D.; ROSSI, G. 1998. An Object Oriented Approach to Web-Based Application Design. Theory and Practice of Object Systems. Wiley. SCOTT, K. 2003. O Processo Unificado Explicado. Porto Alegre: Bookman. 152