universidade do vale do itajaÍ centro de educaÇÃo de ...siaibib01.univali.br/pdf/luciene...
TRANSCRIPT
CUUNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE EDUCAÇÃO DE CIÊNCIAS TECNOLÓGICAS, DA
TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROPOSTA DE DIAGRAMA VOLTADO A SISTEMAS COM ABORDAGEM DE AUTORIA BASEADA EM LINHA DE TEMPO
Área de Engenharia de Software
Luciene Vaz Peixoto Ferrão
Itajaí (SC), Novembro de 2003.
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE EDUCAÇÃO DE CIÊNCIAS TECNOLÓGICAS, DA
TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
RELATÓRIO DO TRABALHO DE CONCLUSÃO DE CURSO II PROPOSTA DE DIAGRAMA VOLTADO A SISTEMAS COM ABORDAGEM
DE AUTORIA BASEADA EM LINHA DE TEMPO
Área de Engenharia de Software
Luciene Vaz Peixoto Ferrão
Relatório apresentado à Banca
Examinadora do Trabalho de Conclusão
do Curso de Ciência da Computação para
análise e aprovação
Itajaí (SC), Novembro de 2003.
i
EQUIPE TÉCNICA
Acadêmica
Luciene Vaz Peixoto Ferrão
Professora Orientadora
Fabiane Barreto Vavassori, Dra.
Coordenadora dos Trabalhos de Conclusão de Curso
Anita Maria da Rocha Fernandes, Dra.
Coordenador do Curso
Luis Carlos Martins, Esp.
ii
DEDICATÓRIA
Dedico este trabalho a minha
família e a todos que fazem parte da
minha vida. Em especial, quero
dedicá-lo ao amigo Jesiel que muito
me ajudou. Que este possa lhe
inspirar a também terminar o curso de
bacharelado em ciência da
computação.
iii
SUMÁRIO
LISTA DE SIGLAS E ABREVIATURAS ...................................VII
LISTA DE FIGURAS .................................................................. VIII
LISTA DE QUADROS ..................................................................... X
LISTA DE ANEXOS....................................................................... XI
RESUMO ...................................................................................... XIII
ABSTRACT ...................................................................................XIV
I - INTRODUÇÃO .............................................................................1
1. APRESENTAÇÃO .......................................................................................... 1
2. JUSTIFICATIVA ............................................................................................ 2
3. IMPORTÂNCIA.............................................................................................. 2
4. OBJETIVOS DO TRABALHO ..................................................................... 3
4.1. Objetivo Geral............................................................................................... 3
4.2. Objetivos Específicos.................................................................................... 3
5. METODOLOGIA............................................................................................ 3
II - REVISÃO BIBLIOGRAFICA....................................................5
1. FERRAMENTAS BASEADAS EM LINHA DE TEMPO.......................... 5
1.1. Discreet 3ds max ........................................................................................... 5
1.2. Macromedia Flash ........................................................................................ 8
1.3. Adobe Premiere .......................................................................................... 10
1.4. Análise Comparativa dos SBLT´s............................................................. 11
2. MACROMEDIA FLASH ............................................................................. 12
2.1. Estrutura da Interface Macromedia Flash .............................................. 14
2.2. Interação do Flash com Fontes Externas ................................................. 17
2.2.1. Flash e XML.............................................................................................. 18
2.2.2. Flash e PHP ............................................................................................... 19
iv
2.2.3. Flash e ASP ............................................................................................... 19
3. UML – LINGUAGEM UNIFICADA DE MODELAGEM....................... 20
3.1. História da UML......................................................................................... 21
3.2. Importância da Especificação de Sistemas. ............................................. 24
3.3. Estrutura da UML...................................................................................... 25
3.3.1. Diagrama de Caso de Uso ......................................................................... 26
3.3.2. Diagrama de Classes.................................................................................. 28
3.3.3. Diagrama de Objetos ................................................................................. 30
3.3.4. Diagrama de Gráfico de Estados ............................................................... 31
3.3.5. Diagrama de Atividades ............................................................................ 33
3.3.6. Diagrama de Seqüência ............................................................................. 34
3.3.7. Diagrama de Colaboração ......................................................................... 35
3.3.8. Diagrama de Componentes........................................................................ 36
3.3.9. Diagrama de Implantação.......................................................................... 37
3.4. Mecanismo de extensão da UML. ............................................................. 38
3.4.1. Estereótipos ............................................................................................... 38
3.4.2. Valores Atribuídos..................................................................................... 39
3.4.3. Restrições................................................................................................... 40
4. PROCESSO DE DESENVOLVIMENTO. ................................................. 40
4.1. Processos de Software ................................................................................ 40
4.1.1. RUP – Rational Unifed Process ................................................................ 41
4.1.1.1. Fase......................................................................................................... 42
4.1.1.2. Concepção .............................................................................................. 43
4.1.1.3. Elaboração .............................................................................................. 43
4.1.1.4. Construção .............................................................................................. 44
4.1.1.5. Transição ................................................................................................ 45
4.1.1.6. Iterações.................................................................................................. 45
4.1.1.7. Workflow................................................................................................ 46
v
III - DESENVOLVIMENTO ..........................................................47
1. NOTAÇÃO DO DIAGRAMA PROPOSTO............................................... 47
1.1. Estereótipos ................................................................................................. 48
1.1.1. Tag’s .......................................................................................................... 48
1.1.2. Constraint................................................................................................... 49
1.2. Notação ........................................................................................................ 49
1.3. Regras para construção ............................................................................. 52
1.4. Visão Geral do Diagrama Proposto .......................................................... 55
1.4.1. Especificação da Cena............................................................................... 56
2. CONFIGURAÇÃO DE FERRAMENTA CASE ....................................... 57
3. INTEGRAÇÃO DIAGRAMA PROPOSTO COM PROCESSO DE
DESENVOLVIMENTO DE REFERÊNCIA ................................................. 62
4. ESTUDO DE CASO ...................................................................................... 63
4.1. Aplicação projeto de trabalho ................................................................... 64
4.1.1. Descrição ................................................................................................... 65
4.1.2. Diagramas.................................................................................................. 66
4.1.2.1. Use-Case: Projeto de trabalho ................................................................ 66
4.1.2.2. SBLT: Projeto de trabalho...................................................................... 68
4.1.2.3. Diagrama E-R: Projeto de trabalho ........................................................ 70
4.1.3. Implementação........................................................................................... 70
4.2. Projeto Web ................................................................................................. 73
4.2.1. Descrição ................................................................................................... 73
4.2.2. Diagrama ................................................................................................... 74
4.2.2.1. Use-case: Softvali ................................................................................... 74
4.2.2.2. SBLT: Softvali........................................................................................ 77
4.2.2.3. Diagrama E-R: Softvali .......................................................................... 82
4.2.3. Implementação........................................................................................... 82
vi
4.3. Engenharia Reversa ................................................................................... 85
4.3.1. Descrição ................................................................................................... 85
4.3.2. Diagrama ................................................................................................... 85
4.3.2.1. Diagrama de use case: Supermercado .................................................... 86
4.3.2.2. Diagrama SBLT: Supermercado ............................................................ 86
4.3.2.3. Diagrama E-R: Supermercado................................................................ 90
4.3.3. Implementação........................................................................................... 91
IV - CONCLUSÃO E RECOMENDAÇÕES.................................93
BIBLIOGRAFIA..............................................................................95
ANEXO ...........................................................................................100
vii
LISTA DE SIGLAS E ABREVIATURAS
ASP Active Server Pages
CAD Computer Aided Design
CASE Computer Aided Software Engineering
CGI Comon Gateway Interface
CNPq Conselho Nacional de Desenvolvimento Científico e Tecnológico
HTML Hiper Text Markup Language
LAN Local Area Network
OMG Object Management Group
OMT Object Modeling Technique
OOSE Object-Oriented Software Engineering
PAN Personal Area Network
PHP Hipertext PreProcessor
RTF Revision Task Force
RUP Rational Unified Process
SBLT Sistemas Baseados em Linha de Tempo
UML Unifield Modeling language
WAN Wide Area Network
XML eXtensible Markup Language
viii
LISTA DE FIGURAS
Figura 1: Pontos de visão do 3ds Max 4. .............................................................................................6
Figura 2: Janela de representação do Track View ................................................................................7
Figura 3: Curvas de funções que direcionam os movimentos do objeto..............................................8
Figura 4: Visualização da interface com um objeto. ............................................................................9
Figura 5: Tela de referencia Timeline. ...............................................................................................10
Figura 6: Ambiente de trabalho para edição de trilhas de vídeos. .....................................................11
Figura 7: Estrutura dos arquivos de publicação em Flash..................................................................13
Figura 8: Apresentação da linha de tempo e da disponibilização de seus componentes. ..................15
Figura 9: a) Estrutura da interface do Flash b) Modelo de relacionamento entre os elementos que
constituem a interface do Flash. .................................................................................................17
Figura 10: O fluxo e a conversão de dados entre um filme do Flash. ................................................18
Figura 11: Origem e evolução da UML. ............................................................................................23
Figura 12: Diagrama de caso de uso ..................................................................................................27
Figura 13: Interação do Ator com casos de uso. ................................................................................28
Figura 14: Diagrama de classes..........................................................................................................30
Figura 15: Diagrama de Objeto Mostrando Exemplos de Instâncias de Grupo.................................31
Figura 16: Diagrama de gráficos de estados para uma lâmpada. .......................................................32
Figura 17: Representação de um diagrama de atividade....................................................................34
Figura 18: Diagrama de seqüência. ....................................................................................................35
Figura 19: Diagrama de colaboração. ................................................................................................36
Figura 20: Diagrama de componentes................................................................................................37
Figura 21: Diagrama de utilização. ....................................................................................................38
Figura 22: O ciclo de vida de desenvolvimento de um software no RUP. ........................................42
Figura 23: Relacionamento entre os elementos do diagrama.............................................................53
Figura 24: Detalhamento do filme. ....................................................................................................55
Figura 25: Detalhamento da Cena 2. ..................................................................................................56
Figura 26: Exemplo de importação de arquivo XML. .......................................................................60
Figura 27: Exemplo de importação do arquivo XML. .......................................................................61
Figura 28: Exemplo dos estereótipos já importados na ferramenta. ..................................................61
Figura 29: Pontos de integração no RUP. ..........................................................................................62
ix
Figura 30: Integração entre os diagramas. .........................................................................................62
Figura 31: Exemplo de integração Caso de Uso – Cena ....................................................................63
Figura 32: Diagrama de use-case do sistema projeto de trabalho. .....................................................66
Figura 33: Diagrama SBLT do sistema projeto de trabalho...............................................................69
Figura 35: Diagrama SBLT parcial de projeto de trabalho. ...............................................................71
Figura 36: Tela de cadastro de projeto. ..............................................................................................72
Figura 37: Tela de detalhes de projeto. ..............................................................................................72
Figura 38: Mensagem do sistema.......................................................................................................72
Figura 39: Diagrama de use-case do sistema Softvali........................................................................75
Figura 40: Diagrama SBLT das cenas o sistema Softvali. .................................................................78
Figura 41: Especificação da cena download do sistema Softvali.......................................................79
Figura 42: Especificação da cena cadastro do sistema Softvali. ........................................................79
Figura 43: Especificação da cena relatos do sistema Softvali............................................................80
Figura 44: Especificação da cena FAQ do sistema Softvali. .............................................................81
Figura 45: Especificação da cena contato do sistema Softvali...........................................................81
Figura 46: Diagrama E-R do sistema Softvali. ..................................................................................82
Figura 47: Diagramação parcial SBLT do sistema Softvali...............................................................83
Figura 48: Tela de cadastramento para disponibilizar download.......................................................83
Figura 49: Tela de mensagem do sistema. .........................................................................................84
Figura 50: Tela disponível para download de arquivos. ....................................................................84
Figura 51: Diagrama de use-case do sistema Supermercado. ............................................................86
Figura 52: Cena 1 do sistema Supermercado. ....................................................................................87
Figura 53: Especificação do mapa de localização do supermercado. ................................................88
Figura 54: Especificação da gôndola da padaria. ...............................................................................89
Figura 55: Especificação da gôndola. ................................................................................................89
Figura 56: Especificação dos carrinhos do supermercado. ................................................................90
Figura 57: Diagrama E-R do sistema supermercado..........................................................................90
x
LISTA DE QUADROS
Quadro 1: Notação do diagrama.........................................................................................................52
Quadro 2: Arquivo XML....................................................................................................................60
Quadro 3: Descrição dos cenários do projeto de trabalho..................................................................68
Quadro 4: Arquivo PHP que lista detalhes do projeto. ......................................................................73
Quadro 5: Cenários do sistema Softvali. ............................................................................................76
Quadro 6: Arquivo PHP que lista os arquivos disponíveis. ...............................................................84
Quadro 7: Cenário do sistema Supermercado. ...................................................................................86
xi
LISTA DE ANEXOS
1. TELAS DO SISTEMA PROJETO DE TRABALHO
Tela 1 Abertura do sistema (Cena 1 – quadro-chave 1).
Tela 2 Cadastro de Professor (Cena 1 – quadro-chave 2).
Tela 3 Cadastro de Turma (Cena 1 – quadro-chave 4).
Tela 4 Cadastro de Projeto (Cena 1 – quadro-chave 3).
Tela 5 Cadastro de Atividade (Cena 1 – quadro-chave 5).
Tela 6 Detalhes de Professor (Cena 1 – quadro-chave 6).
Tela 7 Detalhes de Turma (Cena 1 – quadro-chave 7).
Tela 8 Detalhes de Atividade (Cena 1 – quadro-chave 9).
Tela 9 Mensagem do Sistema (Cena 1 – quadro-chave 9 ao 13).
Tela 10 Mensagem do Sistema (Cena 1 – quadro-chave 15 ao 17).
Tela 11 Mensagem do sistema (Cena 1 – quadro-chave 22).
2. TAGS DO SISTEMA PROJETO DE TRABALHO
3. INTERFACE DO SISTEMA SOFTVALI
Tela 12 Tela de Abertura (Filme 1).
Tela 13 Tela de apresentação do site (Cena 1).
Tela 14 Tela de histórico (Cena 2).
Tela 15 Cadastro (Cena 4).
Tela 16 Tela de relatos (Cena 5).
Tela 17 Resumo da equipe (Cena 6).
Tela 18 Entrada de dados no FAQ (Cena 7).
Tela 19 Envio de e-mail para contato (Cena 8).
Tela 20 Diálogo de erro ao cadastrar o usuário (Cena 4 – quadro-chave 2).
Tela 21 Diálogo de erro ao cadastrar o usuário (Cena 4 – quadro-chave 3).
Tela 22 Mensagem ao cadastrar o usuário (Cena 4 – quadro-chave 4).
Tela 23 Diálogo de erro ao enviar pergunta FAQ (Cena 7 – quadro-chave 2).
4. TAGS DO SISTEMA SOFTVALI
5. INTERFACE DO SISTEMA SUPERMERCADO
xii
Tela 24 Interface que apresenta o supermercado.
Tela 25 Interface que representa a gôndola de frios.
Tela 26 Etiqueta com os dados do sorvete.
6. TAGS DO SISTEMA SUPERMERCADO
xiii
RESUMO
UML é uma linguagem para modelagem de sistemas orientados a objetos que se tornou
padrão para usuários e empresas. Dividida em abordagens funcionalmente diferentes, ela tenta
contemplar todas necessidades de elaboração de um software. Quando a ferramenta de
implementação possui como abordagem o conceito de linha de tempo, alguns aspectos inerentes a
este não são contemplados. A linha de tempo é utilizada em ferramentas que controlam trajetos e
formatos de elementos gráficos, criando a ilusão de movimento. Um caso particularmente recente
da utilização desta idéia é o desenvolvimento de Sistemas de Informações. Habitualmente, a
programação tradicional, orientada a eventos, não necessita das funcionalidades do conceito que a
linha de tempo apresenta, porém, o novo paradigma de sistemas acessíveis através da World Wide
Web, traz a tona esta discussão, pois mesclam interatividade, funcionalidade e alta qualidade gráfica
do conteúdo. O objetivo deste trabalho é estender a UML de forma a atender as necessidades de
modelagem ainda não conhecidos para os Sistemas Baseados em Linha de Tempo utilizando o
software Macromedia Flash como ferramenta de referência. Sendo assim, a proposta consiste em
desenvolver um diagrama visando auxiliar a elaboração de projetos e processo de documentação de
Sistemas Baseados em Linha de Tempo.
xiv
ABSTRACT
UML is a language used to model objetct-oriented systems that has become a standard to
users and enterprises. This graphical language is divided into different funcionalities and it tries to
reach all necessities related to software development. However, there is a lack of components when
the development environment relies on a timeline. Timeline is implemented in tools that need to
control paths and graphical elements, creating movement. A particularly recent utilization of this
idea is the development of Information Systems. Habitually, the traditional programming, guided by
events, does not need the functionalities that this concept presents, however, the new paradigm of
systems accessible through the World Wide Web, brings up this quarrel. This paper's target is to
extend UML in order to provide modeling tools to timeline based systems using Macromedia Flash
as the reference implementation. Thus, the proposal consists of developing new diagrams aiming to
assist the elaboration of projects and process of documentation of timeline based systems.
I - INTRODUÇÃO
1. APRESENTAÇÃO
Os Sistemas Baseados em Linha de Tempo (SBLT) são amplamente utilizados em aplicações
de multimídia. Animações, apresentações, filmes cinematográficos e projetos assistidos por
computador (CAD – Computer Aided Design) estão no rol de abrangência de tais aplicativos.
Particularmente na Internet, os SBLTs são utilizados na elaboração de conteúdo interativo e
mais sofisticado, se comparado com os padrões que a linguagem HTML (Hyper-Text Markup
Language) fornece.
No que se refere à documentação de SBLT, a indústria de informática vem oferecendo
soluções que buscam minimizar dificuldades reproduzindo ou simulando modelos da realidade de
forma mais amigável através de ambientes gráficos e interfaces ricas. Tais fatores levam a crer que
os problemas estão deixando de ser o software ou hardware para se tornarem os métodos de
modelagem empregados no uso das novas tecnologias (FURLAN, 1998).
Devido ao aparecimento de ferramentas que empregam o conceito de linha de tempo e a
grande aceitação delas tanto no meio acadêmico quanto no comercial, decorre a necessidade de
elaborar métodos para documentação de tal conceito aplicado.
No que tange a documentação de um sistema, atualmente, a UML (Unified Modeling
Language) vem se destacando. Segundo Furlan (1998), a UML é uma linguagem para especificar,
visualizar, documentar e construir artefatos de um sistema e pode ser utilizada em todos os
processos do ciclo de desenvolvimento de um software.
Assim, o foco deste trabalho está voltado para a proposta de um diagrama, baseando na UML,
para sistemas baseado em linha de tempo, tentando suprir a carência de documentação para esse
tipo de software.
2
2. JUSTIFICATIVA
Em um processo de desenvolvimento de software, segundo Paula (2001) é necessário uma
documentação que detalhe as atividades desenvolvidas em cada etapa. As dificuldades de
documentação, diagramação e especificação de processos crescem na mesma proporção do sistema
em desenvolvimento, não sendo diferente com os sistemas baseados em linha de tempo. Será
realizado um estudo para definir a ferramenta que servirá de base para a concepção do diagrama
proposto.
Visto que não foi encontrado nenhum tipo de padronização para SBLT, Muller (2001) em seu
trabalho sobre Bibliotecas Digitais via Internet, se deparou com a dificuldade de especificar
adequadamente alguns recursos apresentados. Tal dificuldade decorreu, principalmente, da
inexistência de métodos de documentação específica para a ferramenta utilizada.
Assim, considerando a importância da especificação de sistemas e, tendo em vista a ausência
de métodos voltados especificamente para ferramentas que utilizam a abordagem de linha de tempo,
tem-se uma lacuna a ser preenchida na qual a presente proposta vem a contribuir.
3. IMPORTÂNCIA
Benefícios como o da documentação e análise, permitem interação entre equipes de trabalho
que desenvolvem sistemas em comum. Segundo Larman (2000), um sistema, de um modo geral é
complexo, por isso é necessário decompô-lo em pedaços compreensíveis, de forma a poder
compreender e administrar a complexidade do mesmo. Esses pedaços são representados como
modelos que descrevem e abstraem aspectos essenciais do sistema.
Desse modo, a construção de um diagrama que organize e facilite a compreensão do
comportamento do sistema é de suma importância para quem utiliza SBLTs.
3
4. OBJETIVOS DO TRABALHO
4.1. Objetivo Geral
O objetivo deste trabalho é propor um diagrama para auxiliar o desenvolvimento de projetos e
na documentação de sistemas baseado em linha de tempo, com base na ferramenta que deverá ser
indicada no decorrer do trabalho.
4.2. Objetivos Específicos
Os objetivos específicos deste trabalho são:
⇒ Elaborar uma notação e regras de utilização que virão a compor o diagrama para
SBLT.
⇒ Estudar um processo de desenvolvimento baseado na UML e identificar a integração
do diagrama proposto.
⇒ Desenvolver uma aplicação como estudo de caso visando demonstrar a aplicabilidade
do diagrama proposto.
5. METODOLOGIA
A metodologia deste trabalho visa seguir as fases:
⇒ Para elaboração da notação necessita-se pesquisar e analisar ferramentas que utilizam
Timeline (linha de tempo), para comparação e avaliação. Escolher a ferramenta que
será usada no desenvolvimento do projeto e justificá-la apresentando suas principais
funcionalidades.
⇒ Após a escolha da ferramenta, será feita análise e especificação do seu uso verificando
as subdivisões de objetos e componentes para montagem inicial do diagrama.
4
⇒ Estudar qual dos tópicos usados dentro da UML que servirá de base para análise, em
nível de comparação e junção de componentes para criação e especificação das
primeiras regras.
⇒ Especificadas as regras, será iniciado a montagem do diagrama, a análise será baseada
em testes que serão feitos usando software já desenvolvidos ou em desenvolvimento
para validação.
⇒ Definir o processo de desenvolvimento, ou seja, o caminho mais coerente que deve ser
seguido pelo desenvolvedor do sistema.
⇒ Aplicar o diagrama e o processo de desenvolvimento devidamente testado para
demonstrar sua eficácia.
II - REVISÃO BIBLIOGRAFICA
1. FERRAMENTAS BASEADAS EM LINHA DE TEMPO
Uma animação, de maneira geral, é composta de uma seqüência de imagens estáticas (frames)
que são exibidas em uma velocidade constante, dando a ilusão de movimento, desta forma, os
sistemas que utilizam linhas de tempo são usados para controlar os movimentos e formatos,
controlando seqüências de som. Turquetti (1998), relata que o objeto é desenhado em posições pré-
determinadas, cada uma formando um quadro, e a seqüência de movimentos dos quadros cria a
ilusão de animação.
Em pesquisas realizadas na Internet, notou-se que as ferramentas mais referenciadas quando o
conceito pesquisado refere-se a timeline são:
⇒ Discreet 3ds max;
⇒ Macromedia Flash;
⇒ Adobe Premier.
A seguir será feita uma breve explanação das ferramentas visando selecionar uma delas para
base no trabalho proposto, por sua vez a ferramenta escolhida será melhor detalhada em seção
específica.
1.1. Discreet 3ds max
Segundo Murdock (2001), Discreet 3ds max é a solução mais popular para modelagem de
animações, renderização de filmes, jogos e visualização de projetos. É utilizado para criar
animações no computador onde são simulados objetos reais em terceira dimensão. Os objetos de
uma cena, uma vez construídos são iluminados e filmados com diversos tipos de luzes e câmeras,
como se estivesse em um estúdio de filmagem real.
6
MaxScript é uma linguagem existente dentro do 3ds max que pode ser usada para simplificar
tarefas complexas, dando lhe o controle completo de seu trabalho e a habilidade de criar
ferramentas feitas sob encomenda, bem como realçar as funcionalidades do objeto.
Segundo Takaishi (1998), com o 3ds max é possível realizar animações simples, como por
exemplo, fazer um objeto explodir aplicando efeito bomba ou animações complexas, como
observados em animações de robô em movimento. É válido acrescentar que o 3ds max é utilizado
para os objetos criados no AutoCad, que permite um maior grau de precisão na edição de objetos.
Este software apresenta muitos recursos como ferramentas de efeitos, filtros e deformadores,
muito utilizado em construções civís, serve como modelo de apresentação e perspectiva,
demonstrando uma prévia do projeto a ser desenvolvido (MURDOCK, 2001).
Figura 1: Pontos de visão do 3ds Max 4.
Fonte: Murdock (2001).
7
O seu ambiente inicial é composto de quatro pontos de visão (Figura 1), sendo eles topo,
frente, esquerda e perspectiva, auxiliando na compreensão de modelos 3D. A interface padrão do
3ds max é ilustrada na Figura 1.
A Figura 2 ilustra o conceito de linha de tempo, no 3ds max denominado Track View,
representada por keyframes (camadas de organização das cenas).
Figura 2: Janela de representação do Track View Fonte: Murdock (2001).
As curvas apresentadas na Figura 3 definem o movimento do objeto tridimensional, que irá
para cima e para baixo através do eixo Z e que gradualmente se moverá para direita ao longo do
eixo X.
8
Figura 3: Curvas de funções que direcionam os movimentos do objeto. Fonte: Murdock (2001).
1.2. Macromedia Flash
O Macromedia Flash é um software aplicativo que permite a criação e distribuição de
animações, apresentações, aplicativos e sites de web para diversas plataformas e usando pequena
largura de banda. Ele permite criar e importar gráficos e texto, adicionar animações e interatividade.
O Macromedia Flash é uma ferramenta bastante flexível, atendendo a diversas áreas, tais como
sites, aplicativos, criação de formulários e funções avançadas proporcionadas pelo ActionScript, a
linguagem de scripts do Macromedia Flash (REY, 2002).
Algumas das funcionalidades implementadas pela ferramenta, de acordo com Rey (2002) são:
⇒ Criar gráficos vetoriais, incluindo curvas de Bézier;
⇒ Importar imagens de bitmap e vetoriais;
⇒ Incorporar texto formatado e hyperlinks;
⇒ Adicionar animações e interatividade ao trabalho;
⇒ Criar esquemas de navegação;
9
⇒ Adicionar ações aos filmes;
⇒ Criar bibliotecas reutilizáveis, que podem ser compartilhadas por vários filmes;
⇒ Adicionar e editar sons;
⇒ Desenvolver aplicativos com bancos de dados;
⇒ Possibilita comunicação por meio de ferramentas que usam linguagens como Pl/Sql,
Delphi, Php e Asp.
A Figura 4 mostra a interface do Macromedia Flash, seus principais componentes e entre eles
o palco, o linha de tempo (timeline), as camadas, entre outros.
Figura 4: Visualização da interface com um objeto. Fonte: Reinhardt & Lentz (2001)
10
1.3. Adobe Premiere
Fornece um ambiente completo para edição e produção de vídeos digitais. As aplicações vão
de pequenos clipes de vídeo a inserção de complexos efeitos especiais em produções
cinematográficas. Outro uso freqüente desta ferramenta é a criação de títulos de rodapé utilizados,
por exemplo, nos canais de notícias de televisão (DROBLAS & GEENBERG, 2001).
Dentre suas principais características destaca-se:
⇒ Capturar vídeo a partir de câmeras digitais ou vídeos-cassete;
⇒ Capturar áudio de dispositivos de som;
⇒ Criar legendas e títulos de rodapé;
⇒ Integrar arquivos de diferentes origens dentro de uma produção;
⇒ Criar efeitos especiais como distorções e suavizações;
⇒ Criar efeitos de movimentação de gráficos na tela;
⇒ Mesclar vários vídeos em apenas um.
As Figuras 5 mostra a tela com apresentação do timeline da ferramenta, e a Figura 6 mostra a
interface do Adobe Premier, como ela é dividida para facilitar a edição de vídeos.
Figura 5: Tela de referencia Timeline. Fonte: Droblas & Geenberg (2001)
11
Figura 6: Ambiente de trabalho para edição de trilhas de vídeos. Fonte: Droblas & Geenberg (2001)
1.4. Análise Comparativa dos SBLT´s
Os três softwares revisados neste capítulo, exploram as possibilidades de aplicação do
conceito de SBLT. Sendo assim, a Tabela 1, resume as principais características.
Tabela 1: Comparação das ferramentas SBLT Ferramenta Discreet 3ds max Macromedia Flash Adobe Premiere
Conceitos
Criar animações no computador onde são
simulados objetos reais em terceira dimensão.
Criação e distribuição de animações, aplicativos e site
de web para diversas plataformas.
Edição e produção de
vídeos digitais
Aplicação
Apresentação de um novo produto ou
criação de animações para filmes
cinematográficos.
Criação de animações com interatividade.
Desenvolvimento de aplicações utilizando
ActionScript.
Edição de filmes cinematográficos.
12
Considerando que a proposta visa desenvolver um diagrama voltado para SBLT e que tem
como finalidade principal ser utilizado para auxiliar a documentação de sistemas, considera-se que a
ferramenta Macromedia Flash seja um referencial adequado, pois, possui dentre todas as
ferramentas analisadas, uma linguagem ActionScript que permite o desenvolvimento de aplicativos
completos, incluindo a integração com outras linguagens e banco de dados.
2. MACROMEDIA FLASH
Conforme abordado na seção 1 deste capítulo (Ferramentas Baseadas em Linha de Tempo), o
Flash mostrou-se suficientemente adequado servindo de guia para desenvolvimento do diagrama.
Sendo assim, esta seção detalha a ferramenta Flash, com ênfase para elaboração de aplicativos,
organização dos recursos e sua interface.
O Macromedia Flash é a ferramenta de autoria para criação de animações e controles para
navegação em sites da web. Além das funcionalidades básicas, nas últimas versões da ferramenta,
segundo Behzadi (2002), houveram diversas melhorias especialmente voltadas ao desenvolvimento
de aplicativos. Com isso, pode-se criar telas de interface de usuário, quase que inteiramente em
código, criando-se enormes possibilidades para o Macromedia Flash MX ser usado como camada
visual de front-end para muitos aplicativos empresariais baseados na web. Outra característica que
habilita Macromedia Flash (na sua versão MX) para o desenvolvimento de aplicativos refere-se ao
suporte a troca de dados no formato XML (Extensible Marckup Language).
Ainda no que se refere ao desenvolvimento de aplicativos em Flash, conforme Perry (2003),
tal ferramenta não está restrita somente ao desenvolvimento de aplicativos para desktop, podendo
ser utilizada também no desenvolvimento de aplicativos para Pocket PCs, WebTV e outras
plataformas. Tanto o Macromedia Flash quanto os Pocket PCs, como as demais plataformas, estão
em vias de tornar possível aos usuários interagirem com conteúdo dinâmico em uma interface
gráfica sofisticada enquanto estão conectados a redes PAN (Personal Área Network ), LAN (Local
Área Network) por meio de dispositivos móveis sem fio.
13
A estrutura dos arquivos no Macromedia Flash é representada pelas extensões fla e/ou swf. Os
arquivos do tipo fla são criados automaticamente na interface inicial do sistema, nele se apresentam
todas as informações necessárias para o desenvolvimento do projeto e testes de material interativo.
Esses documentos não podem ser publicados, na verdade os documentos fla são trabalhados como
filmes do Flash. Já os arquivos do tipo swf são os arquivos gerados pelo fla, seria como os
executáveis ou resultados do projeto desenvolvido, que contém apenas as informações necessárias
para exibição do filme. O documento publicável é o swf, que ainda pode ser gerado como anexo de
uma página HTML, como exemplo na Figura 7.
Figura 7: Estrutura dos arquivos de publicação em Flash.
Devido ao uso de linha de tempo, o Flash vem a facilitar criações de aplicativos com
animações. O software cria um arquivo cujo nome usado é filme, sendo que o filme contém o
código e a maioria dos itens que serão disponibilizados no projeto. Os filmes são constituídos por
gráficos, texto, animação. Eles consistem principalmente em gráficos vetoriais, que podem
ocasionalmente conter vídeo, gráficos de bitmap e sons importados. Ele ainda pode incorporar
interatividade, além disso, é possível criar filmes não-lineares que podem interagir com outros
aplicativos da web. Os webdesigner utilizam o Macromedia Flash para criar controles de
navegação, logotipos animados, animações extensas com som sincronizado. Seus filmes usam
elementos gráficos vetoriais compactos.
14
2.1. Estrutura da Interface Macromedia Flash
Para se criar e distribuir filmes em Macromedia Flash é necessário trabalhar dentro do seu
próprio ambiente de desenvolvimento. Os recursos oferecidos pela ferramenta estão bem
distribuídos para a criação e desenvolvimento do filme. Nesta seção serão abordados e conceituados
apenas os recursos necessários para criação e desenvolvimento do diagrama proposto.
As partes que formam o ambiente Macromedia Flash podem ser classificadas segundo Rey
(2002) em:
⇒ Filme: estrutura de dados que armazena o conjunto de informações relativas ao filme
em um arquivo manipulado pelo Flash;
⇒ Linha de Tempo: é a grade onde se coordena a cronometragem de animações. A
janela de linha de tempo exibe cada quadro de um filme, cada camada aparece na linha
de tempo como uma sub-linha separada;
⇒ Quadros (Frames): A animação é constituída por uma série de quadros, que definem
o conteúdo e o tempo de execução de um filme. As imagens são alternadas quadro a
quadro, formando a impressão de animação. Se a alteração de cada imagem for
pequena e os quadros se moverem rapidamente, o movimento como de um filme terá
uma aparência suave;
Um caso particular de quadro é o quadro-chave ou keyframe. Este quadro-chave define
alterações na animação ou inclui ações de quadro para modificá-lo. O Flash interpola
ou preenche os quadros entre quadros-chave para produzir animações. Como os
quadros-chave permitem produzir animação sem a necessidade de desenhá-los quadro
a quadro, a ordem na qual os quadros e quadros-chave aparecem na linha de tempo
determina a seqüência em que eles são exibidos em um filme;
⇒ Camadas (layer): são como uma pilha de transparências de acetato. Pode-se separar os
elementos das ilustrações em camadas para modificá-las e manuseá-las. Essas camadas
podem ser usadas sem limites, pois elas não aumentarão o tamanho do arquivo.
⇒ Palco é o local em que o usuário elabora os quadros do filme, seja desenhando as
ilustrações diretamente nele ou inserindo ilustrações importadas;
⇒ Cenas: São utilizadas para organização dos filmes, onde se pode criar uma animação
dentro do filme;
15
Na Figura 8 estão destacados os tópicos citados acima, para uma melhor visualização de
como são representados na interface da ferramenta.
⇒ Biblioteca: é o local onde se armazena e se organiza os símbolos criados no Flash. Ela
armazena arquivos importados, sons, imagens de bitmap e filmes. Permite organização
em pastas, verificação da freqüência de utilização de um item em um filme e
classificando os itens por tipo;
⇒ Símbolos: são objetos que podem ser reutilizados. Aparecem listados na biblioteca,
onde se pode controlar e administrar todos eles. São classificados como Gráfico, Botão
ou Movie Clip e assim dispostos para possibilitar a reutilização de um símbolo várias
vezes com propriedades diferentes.
Figura 8: Apresentação da linha de tempo e da disponibilização de seus componentes. Fonte: Macromedia Flash MX (2003).
16
⇒ ActionScript: é a linguagem de programação embutida no Flash. Ela possibilita a
criação de filmes com interatividade, desde botões de ação Play e Stop a scripts
avançados de envio de dados para o servidor. É uma linguagem orientada a objetos e
bastante similar ao JavaScript.
Essa linguagem permite criação de jogos interativos, validação de dados, integração
com server-side scripts (ASP, PHP, CGI, etc) e banco de dados com XML.
O Macromedia Flash inclui um ambiente de desenvolvimento visual e um depurador
(debugger) para correção de erros.
Na Figura 9a e 9b estão representadas as relações dos recursos do Flash, e como eles estão
disponibilizados na interface. Na parte da Figura 9a pode-se verificar o filme como parte principal
do arquivo e dentro dele a disposição da cena e a linha de tempo. Dentro da cena se localiza o palco
onde se pode desenhar ou inserir figuras, tendo-se a opção de transformá-las em símbolos. A linha
de tempo faz parte do filme, tudo que se localiza dentro do filme tem sua linha de tempo que é
constituída de camadas e quadros.
A Figura 9b exibe as relações de cardinalidade entre os componentes que formam um arquivo
de dados do Flash. O filme é composto por uma ou mais cenas. Cada cena implica na existência de
um palco que, por sua vez, opcionalmente exibe figuras ou símbolos, classificados como gráficos,
botões ou filmes aninhados. Também, o filme é controlado por uma linha de tempo, que regula a
exibição do conteúdo existente nas várias camadas da animação, quadro a quadro.
17
Figura 9: a) Estrutura da interface do Flash
b) Modelo de relacionamento entre os elementos que constituem a interface do Flash.
2.2. Interação do Flash com Fontes Externas
Os filmes do Macromedia Flash MX podem enviar informações para fontes externas, bem
como executá-las, usando ações e métodos para se comunicar com scripts do servidor, arquivos de
texto e arquivos XML. (REY, 2002)
Esta seção aborda a forma como acontece essa comunicação, de maneira geral a Figura 10
ilustra a integração do Flash com aplicativos externos, onde são apresentados um script do SSS(
Server Side Script) e um banco de dados. Integração válida para as linguagens que serão citadas
nesta seção. Assim, Flash Movie representa o filme, Server-side são códigos de programa que são
processados no servidor e Database é o banco de dados a ser acessado.
18
Figura 10: O fluxo e a conversão de dados entre um filme do Flash.
2.2.1. Flash e XML
XML, conforme Galvez (2001), é uma linguagem considerada uma extensão do HTML que
surgiu para ampliar os recursos pré-existentes. O ActionScript tem um objeto que permite extrair
dados de um documento XML, integrando dados de diferentes aplicativos.
Os métodos do objeto ActionScript XML (por exemplo, appendChild, removeNode e
insertBefore) permitem estruturar os dados XML no Flash para enviá-los a um servidor, para
manipular e interpretar estes dados XML. (REY, 2002)
Um exemplo de integração Flash e XML é um sistema de corretagem para a venda de títulos
que armazena todas as suas informações como nomes de usuários, senhas, identificações de sessões,
títulos em carteira e informações sobre transações em um banco de dados. O script do servidor que
transfere as informações entre o Flash e o banco de dados lê e grava os dados no formato XML. O
ActionScript pode ser usado para converter as informações obtidas no filme do Flash, neste
exemplo, um nome de usuário e uma senha em um objeto XML e enviar os dados para o script do
servidor como um documento XML. Também pode-se usar o ActionScript para carregar o
documento XML retornado pelo servidor em um objeto XML e utilizá-lo no filme (REY, 2002).
19
2.2.2. Flash e PHP
PHP é uma linguagem muito utilizada para comunicação entre web servers e bancos de dados.
Uma de suas características é a possibilidade de aceitar extensões de manipulação de diversas
bibliotecas, entre elas a do Shockwave Flash.
Segundo Pinto (2001), uma vez criadas as variáveis basta usar uma ação do ActonScript,
como as chamadas getUrl ou loadVariables, sendo esses comandos utilizados para construção de
arquivos que exigem mudança de conteúdo. Suponha-se que se deseja enviar conteúdo de um
formulário com os campos e-mail e mensagem para um script que, por sua vez, enviará uma
mensagem eletrônica a partir das informações preenchidas no formulário.
Os objetos loadVars transferem dados entre scripts no lado do servidor - como PHP, ASP,
ColdFusion, Perl ou Java Server Pages e filmes Macromedia Flash MX. As propriedades do objeto
loadVars são enviadas ao script como variáveis, pelo método POST ou GET. Todas as variáveis
retornadas do script estão disponíveis como propriedades do objeto loadVars especificado no
método de carregamento. Para exibir texto em filmes é necessário informar um ou vários campos de
texto. Pode-se criar dinamicamente um campo, através de create textFiled, ou estabelecer um campo
no filme (TRIOLO, 2002).
2.2.3. Flash e ASP
De acordo com Universidade Federal Do Piauí (2000 apud MULLER 2001), ASP é uma
tecnologia que utiliza uma linguagem de scripting chamada VBScript, uma versão simplificada do
Visual Basic, que permite a criação de páginas com conteúdo dinâmico. Todo o código de
programação existente em páginas ASP é executado no servidor, e este retorna ao cliente somente
as respostas em HTML padrão, o que faz com que aplicações ASP possam ser acessadas por
qualquer browser existentes no mercado. Uma aplicação feita em ASP pode ainda conter linhas que
serão executadas na estação cliente. Essas páginas devem estar hospedadas num servidor Microsoft
Information Server. A comunicação que essa linguagem usa com o Flash é feita da mesma forma
que PHP.
20
3. UML – LINGUAGEM UNIFICADA DE MODELAGEM
A UML é o resultado da unificação dos métodos Booch, OMT (Object Modeling Technique)
e OOSE (Object-Oriented Software Engineering), dando origem a uma linguagem padronizada para
modelar sistemas de softwares orientados a objeto, que no decorrer do seu desenvolvimento foi
adotada por empresas de software e por fornecedores de ferramentas CASE (Computer Aided
Software Engineering), assim se tornando linguagem padrão (SILVA, 2001).
Linguagem de modelagem é o nome usado para UML, sendo que a linguagem é uma notação
principalmente gráfica utilizada por métodos para expressar projetos. Este capítulo aborda uma
visão geral da UML bem como uma descrição sucinta dos diagramas propostos pela linguagem. No
contexto deste trabalho, este capítulo tem por objetivo fornecer uma base para a elaboração do
diagrama proposto.
A UML segundo Booch et al. (2000), é uma linguagem gráfica para visualização,
especificação, construção e documentação de artefatos de sistemas complexos de software. Ela
proporciona uma forma-padrão para a preparação de planos de arquitetura de projetos de sistemas,
incluindo aspectos conceituais tais como processos de negócios e função do sistema, além de itens
concretos como as classes escritas em determinadas linguagens de programação, esquemas de
banco de dados e componentes de software reutilizáveis.
A escolha da UML para servir de base para o desenvolvimento do diagrama, deve-se ao fato
de que, segundo Wolff (2003), ela é uma linguagem destinada a ser dominante. Além disso, ela
ainda possui o aspecto importante levantado por Wolff, de obter uma grande variedade de
aplicações; é construída com base em uma tecnologia comprovadamente bem estabelecida para
modelagem de sistemas, possui o suporte necessário para conseguir esta padronização no mundo
real. A UML é também amplamente documentada com metamodelos da linguagem, e com uma
especificação formal de semântica.
21
A UML oferece uma linguagem padrão para elaboração de projetos de software, uma única
linguagem não é suficiente para expressar todas as possíveis características de todos os modelos em
qualquer domínio o tempo todo. Por esse motivo a UML permite que se possa ampliar a linguagem
de uma forma controlada. O mecanismo de extensibilidade da UML possibilita a extensão da
linguagem, tendo como características principais: estereótipos, valores atribuídos e restrições
(BOOCH et al., 2000).
3.1. História da UML
As linguagens de modelagem orientadas a objetos surgiram entre a metade da década de 1970
e o final da década de 1980, à medida que as equipes se envolveram com metodologia, diante de um
novo gênero de linguagens de programação orientadas a objeto e de aplicações cada vez mais
complexas, começaram os experimentos de métodos alternativos de análise e projeto. A quantidade
de métodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o período
de 1989 a 1994. Muitos usuários desses métodos tiveram dificuldades para encontrar uma
linguagem de modelagem capaz de atender inteiramente às suas necessidades. Destacaram-se
algumas linguagens como o Booch, o OOSE de Jacobson, e o OMT de Rumbaugh. Pode-se citar
outros métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram métodos
completos, alguns se destacavam em algum ponto, porém tinham suas limitações. O método Booch
destacava-se durante as fases de projeto e construção de sistemas, o OOSE fornecia excelente
suporte para captura de requisitos, a análise e o projeto em alto nível; o OMT-2 era mais útil com a
análise e sistemas de informações com uso de dados (BOOCH et al. 2000).
Na metade da década de 1990, Grady Booch (Rational Software Corporation), Ivar Jacobson
(Objectory) e James Rumbaugh (General Electric) criadores de métodos orientados a objetos,
coletaram várias idéias e começaram a criação de uma linguagem unificada de modelagem. Com
isso esperavam fornecer ao mercado uma linguagem mais concreta e madura com a qual os
desenvolvedores de ferramentas pudessem criar uma ferramenta mais utilizável. Usando técnicas
orientadas a objeto, criariam uma linguagem que iria desde o conceito até o sistema executável
(FURLAN, 1998).
22
A criação da UML iniciou oficialmente em outubro de 1994, quando Rumbaugh se juntou a
Booch na Rational. O foco inicial do projeto era a unificação dos métodos Booch e OMT
(FURLAN, 1998). O esboço da versão 0.8 do Método Unificado foi lançado em outubro de 1995.
Aproximadamente na mesma época Jacobson se associou a Rational com a finalidade de incorporar
o OOSE no escopo inicial da versão 0.8, resultando o lançamento da versão 0.9 da UML em junho
de 1996. Foi então aprovada pela comunidade de engenharia de software em geral. Muitas empresas
se interessaram. Em seguida criou-se um consórcio com várias empresas interessadas em dedicar
recursos com o propósito de trabalhar uma definição mais forte e completa da UML (BOOCH et al.
2000).
Booch, Rumbaugh e Jacobson lançaram algumas versões preliminares da UML à comunidade
de orientação a objetos. As respostas em retorno possibilitaram a eles várias idéias e sugestões a
serem incorporadas a fim de aprimorar a linguagem. A versão 1.0 da UML foi lançada em Janeiro
de 1997, para melhor compreensão a Figura 11 apresenta a evolução das versões UML.
23
Figura 11: Origem e evolução da UML. Fonte: Fowler & Scott, (2000).
O OMG (Object Management Group), adotou a 1.1 resultante como um padrão oficial, desde
então, a RTF (Revision Task Force), dirigida por Cris Kobryn, fez algumas revisões incrementais.
A versão 1.2 foi somente para melhorar as aparências, mas a versão 1.3 tornada pública no início de
1999 tornou-se assim a mais significativa (FOWLER & SCOTT, 2000).
24
Houveram outras atualizações feitas até 2001, entre elas UML 1.4 (Planned minor revision)
em 2000, que é regulamentada pela OMG juntamente com vários fabricantes, como Rational
Software, HP, Oracle, IBM, Unisys, Mci, os quais pretendem torná-la um padrão de fato. Em 2001
os membros da OMG começaram o trabalho de melhoramento para a versão 2.0 (OMG, 2003).
3.2. Importância da Especificação de Sistemas.
Muitos problemas e falhas surgem durante a especificação dos requisitos em virtude das
dificuldades das fases iniciais do desenvolvimento. Incertezas e erros podem ocorrer em função da
má comunicação ou falta de especialistas nas informações do domínio do problema sendo
analisado. Membros da equipe podem apresentar vocabulário conflitante, ambíguo, e má
interpretação dos conceitos e funcionalidades envolvidos, em função do uso de linguagem natural,
não precisa. Há ainda a própria dificuldade do usuário em explicitar de forma completa, clara e
estável seus requisitos. O uso de uma notação precisa que atue como base para evolução,
documentação e comunicação, facilita a organização, o entendimento e a visualização padronizada
do problema.
Modelos fornecem uma cópia do projeto de um sistema, esses documentos são expressos em
uma linguagem, geralmente gráfica, que contêm semânticas interpretáveis de forma fácil para quem
os lê. Modelos permitem obter múltiplas visões do sistema, particionando a complexidade para sua
compreensão e atuando como meio de comunicação entre os participantes do projeto. Portanto, uma
linguagem de modelagem deve conter elementos que representem os conceitos e semânticas
fundamentais, além de uma notação para sua visualização gráfica e regras e conselhos de como usá-
la (BOOCH et al. 2000). Segundo OMG (2003), modelar é uma parte essencial de grandes projetos
do software, e muito útil em pequenos projetos, usando um modelo, os responsáveis pelo
desenvolvimento do software projetaram o sucesso e asseguram a funcionalidade do software. O
uso de modelos consistentes mostra-se um fator determinante para evitar a propagação de erros para
as fases posteriores e diminuir os esforços para corrigí-los.
25
Qualquer projeto será beneficiado pelo uso de algum tipo de modelagem, sendo que uma das
grandes vantagens da UML é o fato dela ser totalmente extensível e adaptável. Sendo apenas
necessário selecionar os elementos da UML que melhor expressarão a modelagem utilizada. Caso o
modelo usado não se encaixe nos elementos disponíveis, é possível estender tais modelos da UML,
e isso pode ser feito sem perder a compreensão da análise escrita, qualquer pessoa da equipe de
desenvolvimento do projeto, entenderá que foi feita uma extensão (MELO, 2003).
Com o uso da modelagem pode se alcançar quatro objetivos de acordo com Booch et al.
(2000):
⇒ Os modelos ajudam a visualizar o sistema como ele é ou como se pretende que ele
seja.
⇒ Os modelos permitem especificar a estrutura ou o comportamento de um sistema.
⇒ Os modelos proporcionam um guia para a construção do sistema.
⇒ Os modelos documentam as decisões tomadas.
3.3. Estrutura da UML
Segundo Melo (2003) a UML tem sua estrutura basicamente dividida em três tipos: elementos
de modelo que podem ser classes, casos de uso, componentes entre outros, diagramas e
relacionamentos. Ainda pode ser citado os mecanismos de extensão que permitem ao desenvolvedor
a flexibilidade de estender seu modelo.
O modo para descrever os vários aspectos de modelagem pela UML é através de notação
definida pelos vários tipos de digramas. Um diagrama é uma apresentação gráfica de uma coleção
de elementos de modelo, freqüentemente mostrando como um gráfico conectado por arcos
(relacionamentos) e vértices (outros elementos do modelo). Modelar um sistema complexo é uma
tarefa extensiva e necessita a descrição de vários aspectos diferenciados, cada visão é descrita em
um número de diagramas que contém informações enfatizando um aspecto particular do sistema
(FURLAN, 1998).
26
Em todos os sistemas, com exceção dos mais triviais, o diagrama representa a visualização
parcial dos elementos que compõem o sistema. O mesmo elemento pode se repetir em vários
diagramas, cada um com a sua utilidade e a maioria dos diagramas contém nós conectados por
caminhos para representar as comunicações ou relacionamentos entre eles (BOOCH et al. 2000).
Por isso a UML disponibiliza nove tipos de diagramas: Diagrama de Casos de Uso, Diagrama de
Classes, Diagrama de Objetos, Diagrama de Gráfico de Estados, Diagrama de Atividades, Diagrama
de Seqüências, Diagrama de Colaborações, Diagrama de Componentes e Diagrama de Implantação.
Esses diagramas permitem a modelagem de todas as fases do ciclo de desenvolvimento de sistemas
(MELO, 2003).
Esses diagramas são sucintamente descritos nas seções a seguir.
3.3.1. Diagrama de Caso de Uso
Segundo Silva (2001), o diagrama de caso de uso representa um conjunto de atores (um tipo
especial de classe), casos de uso e os relacionamentos entre eles.
Os casos de uso descrevem a funcionalidade da aplicação percebida por atores, sendo que
atores são suas entidades externas (FURLAN, 1998). Um ator interage com o sistema podendo ser
um usuário, dispositivo ou sistema. Esses diagramas são importantes principalmente para a
organização e a modelagem do comportamento do sistema (BOOCH et al. 2000).
Os diagramas de caso de usos são aplicados basicamente para fazer modelagem da visão
estática do caso de uso do sistema. Essa visão proporciona suporte principalmente para o
comportamento e como ele deverá agir sob o ponto de vista externo do sistema.
A notação utilizada pela UML para o diagrama de caso de uso encontra-se representada na
Figura 12.
27
Figura 12: Diagrama de caso de uso Fonte: Furlan (1998).
Um caso de uso descreve cenários possíveis dentro de um sistema, composto por seqüências
de passos em que há interação entre usuários e o sistema. De acordo com Silva (2001), as
características de um diagrama de casos de uso são:
⇒ Captar o comportamento desejado para um sistema, por meio de análise dos requisitos
necessários para a construção do sistema.
⇒ Permite enxergar melhor a abrangência dos requisitos de um sistema, pois utiliza-se de
recursos gráficos para estruturar esses requisitos.
⇒ Permite documentar todos os requisitos de um sistema.
⇒ Sua estrutura é extremamente simples, pois os cenários são formados por textos,
descritos em uma linguagem informal, possibilitando o entendimento não somente da
equipe técnica, mas por todos que participam do processo de desenvolvimento de um
sistema.
⇒ Permite organizar os requisitos, eliminando as redundâncias de informação por meio
dos relacionamentos entre os casos de uso.
⇒ Permite identificar os riscos possíveis para a fase de construção do sistema.
⇒ Pode ser usado em todas as fases no desenvolvimento de um sistema, orientado na
definição da arquitetura até os testes funcionais do sistema.
28
Figura 13: Interação do Ator com casos de uso. Fonte: André & Jales (2003).
A Figura 13 representa um cenário onde o ator pode se comunicar com o sistema que na
figura aparece representando um sistema integrado de um banco que se relaciona com seu cliente,
através do envio de mensagens, sendo que a interação se inicia com o estímulo ou mensagem do
ator representado pela administração do banco.
3.3.2. Diagrama de Classes
Conforme Booch et al. (2000), os diagramas de classes são os diagramas usados na
modelagem de sistemas orientados a objetos. Ele mostra basicamente um conjunto de classes,
interface e colaborações e seus relacionamentos.
Um diagrama de classe denota a estrutura estática de um sistema e as classes representam as
manipulações que podem ser feitas no sistema. O diagrama é considerado estático, pois a estrutura
descrita é sempre válida em qualquer ponto do ciclo de vida de um sistema (FURLAN, 1998).
29
O diagrama de classe, segundo Silva (2001), é o centro dos principais conceitos da
modelagem orientada a objetos, ele permite visualizar o modelo da estrutura de um sistema, sendo
um dos diagramas mais utilizados na UML. Esse diagrama contém itens como classes, interface,
relacionamentos (agregação, composição, generalização, etc.) e as colaborações.
As classes representam os blocos de construção utilizados nesse diagrama. São todos os
objetos que interagem de alguma forma para executar um comportamento desejado. A interface é a
coleção de operações utilizadas para especificar um serviço de uma classe ou de um componente
(BOOCH et al. 2000). Já os relacionamentos, por sua vez, informam em um modelo de diagrama de
classes como essas classes estarão de alguma forma ligadas ou associadas para atender as
responsabilidades que lhe foram atribuídas. É também tarefa dos relacionamentos demonstrar os
papéis de casa classe. Os relacionamentos demonstram a importância de cada classe relacionada a
um modelo quando for utilizado o relacionamento do tipo agregação, em que serão demonstradas a
classe superior e suas agregadas. As colaborações representam a forma como as classes interagirão
para executar um comportamento cooperativo (SILVA, 2001).
O diagrama de classes é constituído respectivamente por quatro tipos principais de
relacionamentos. A generalização ou especificação, que indica o relacionamento entre um elemento
mais geral e um elemento mais específico, mais conhecido como herança. A agregação,
normalmente usada para denotar relacionamento todo/parte. A associação engloba o relacionamento
entre classes não correlatas. E por fim a dependência, que refere-se a relacionamentos entre
elementos independentes um do outro, onde uma mudança no elemento não afeta o elemento
dependente (FURLAN, 1998).
Em UML as classes são representadas por um retângulo dividido em três compartimentos: o
compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que possui
a relação de atributos que a classe possui em sua estrutura interna, e o compartimento de operações,
que serão os métodos de manipulação de dados e de comunicação de uma classe com outras do
sistema, conforme se observa na Figura 14.
30
Figura 14: Diagrama de classes. Fonte: André & Jales (2003).
3.3.3. Diagrama de Objetos
Os diagramas de objetos de acordo com Booch et al. (2000), fazem a modelagem de
instâncias de itens contidos em diagramas de classe. O diagrama mostra respectivamente um
conjunto de objetos e seus tipos de relacionamentos em um determinado ponto do tempo.
Este diagrama pode ser considerado uma variação do diagrama de classes, e
conseqüentemente, se utiliza de quase todas as suas notações. O que distingue em um diagrama de
objetos do diagrama de classe é o seu conteúdo particular (SILVA, 2001) ou seja, o diagrama de
objeto mostra um número de instâncias de classes, em vez de uma classe real (FURLAN, 1998).
Os objetos são diferenciados por suas classes por terem os seus nomes sublinhados. Cada
nome assume a forma nome de instância: nome de classe. Apesar de não ser tão importante quanto
o diagrama de classes, o diagrama de objetos pode ajudar na compreensão de diagramas complexos
que não estejam muito claros (FOWLER & SCOTT, 2000).
31
Normalmente os diagramas de objetos contêm objetos e vínculos, e seu foco está voltado para
instâncias concretas. O objeto é a manifestação concreta de uma abstração, ou seja, a instância de
uma classe. Logo, os vínculos são a conexão semântica entre os objetos, e se existir um vínculo
entre dois objetos, um objeto é capaz de enviar uma mensagem ao outro (BOOCH et al. 2000).
Na Figura 15 verifica-se como aparece o nome dos objetos e seus relacionamentos.
Figura 15: Diagrama de Objeto Mostrando Exemplos de Instâncias de Grupo. Fonte: Fowler & Scott (2000).
3.3.4. Diagrama de Gráfico de Estados
Representa todos os estados possíveis de um objeto em particular, bem como as atividades
que devem ocorrer ao longo da vida do objeto. As atividades executadas pelo objeto resultam em
ações que podem ou não mudar o estado atual do objeto (SILVA, 2001). Assim de acordo com
Fowler & Scott, (2000), o diagrama respectivo tem sido utilizado na maioria das técnicas de
orientação a objeto e sua idéia básica é a de estudar tipos de lógicas que envolvem transições
possíveis entre diferentes estados, assim sua técnica é mais usada para descrever o comportamento
de um sistema.
De acordo com Booch et al. (2001), diagramas de gráficos de estados são empregados para a
modelagem dos aspectos dinâmicos de um sistema, na maioria das vezes envolve-se a modelagem
do comportamento de objetos reativo. Sendo que os objetos reativos são aqueles cujo
comportamento é caracterizado por usar respostas a eventos ativados externamente ao seu contexto.
32
Um sistema reage com estímulos externos ou temporais ocorridos como fatos concretos do
mundo físico. A contribuição dessa técnica está em prover uma definição formal explícita de
comportamento, permitindo uma verificação dos eventos e transições de estados aos quais um
sistema está sujeito (FURLAN, 1998).
A existência de estado nos objetos implica na importância com que a ordem das operações são
executadas, o que leva a idéia de objetos como máquinas independentes. Assim, os objetos de uma
classe habitualmente possuem um ciclo de vida; são gerados, assumem posições durante a sua vida,
dão origem a outros objetos em classes relacionadas e deixam de existir no momento de sua
destruição (FURLAN, 1998).
Os diagramas de estados são ideais para descrição de comportamento de um único objeto, não
para descrever adequadamente o comportamento quando se envolve vários objetos. Os estados
modelam a dinâmica existente de em sistema, evento é uma ocorrência de um estímulo gerado para
o objeto, capaz de fazer a mudança de seu estado. Já a transição é um relacionamento entre dois
estados, na Figura 16 tem-se um exemplo do diagrama de estados (FURLAN, 1998).
Figura 16: Diagrama de gráficos de estados para uma lâmpada. Fonte: Silva (2001).
33
3.3.5. Diagrama de Atividades
Esse diagrama representa um fluxo de controle de atividade, que ocorrem no processo de um
sistema, oferecendo suporte para o comportamento condicional e paralelo. Com o diagrama de
atividade é possível também fazer a modelagem do fluxo de atividades de um objeto específico, por
meio das transições de estado que um objeto sofre durante sua existência.O diagrama de atividades
descreve a seqüência de atividades. O respectivo diagrama é uma variante de um diagrama de
estados no qual a maioria, se não todos, dos estados é estado de atividade. Portanto, muito da
terminologia se assemelha ao diagrama de estado (SILVA, 2001).
O comportamento condicional é delineado por desvios (Branches) e intercalações (Merges).
Um desvio é uma transição de entradas únicas e várias transições de saída guardadas. A intercalação
tem múltiplas transições de entrada e uma única saída (FOWLER & SCOOT, 2000).
Um comportamento paralelo é indicado por separações (Forks) e junções (Joins). Quando se
tem uma transição de entrada e várias transições de saída é denominado separação. Quando se tem
comportamento paralelo é preciso sincronizá-lo, o comportamento de junção serve para que a
transição seguinte só seja efetuada quando todos os estados na transição de entrada tenham
completado suas atividades. Assim separação e junção devem se completar. A Figura 17 mostra
como pode ser visualizado o diagrama em questão (FOWLER & SCOOT, 2000).
34
Figura 17: Representação de um diagrama de atividade. Fonte: André & Jales (2003).
3.3.6. Diagrama de Seqüência
Os diagramas de seqüência e de colaboração são chamados de diagrama de interação e são
utilizados para modelagem dos aspectos dinâmicos dos sistemas. Um diagrama de interação mostra
uma interação formada por um conjunto de objetos e seus relacionamentos incluindo as mensagens
que poderão ser enviadas entre eles. Um diagrama de seqüência é um diagrama de interação que dá
ênfase a ordenação temporal das mensagens (BOOCH et al. 2000). Segundo Paula (2001), os
diagramas de seqüência enfatizam o ordenamento temporal das ações, as quais são representadas
por mensagens
Graficamente, um diagrama de seqüência é uma tabela que mostra objetos distribuídos no
eixo X e mensagens, em ordem crescente no tempo, no eixo Y. (BOOCH et al. 2000).
35
Figura 18: Diagrama de seqüência. Fonte: André & Jales (2003).
3.3.7. Diagrama de Colaboração
Uma colaboração é uma sociedade de classes, interfaces e outros elementos que trabalhem
em conjunto para fornecer algum comportamento cooperativo maior que a soma de suas partes. De
forma geral, ela também pode ser a especificação do modo como um elemento ou uma operação, é
realizada por um conjunto de classificadores e associações desempenhando papéis específicos
(BOOCH et al. 2000).
Dentro de um diagrama de colaboração, os objetos são mostrados como ícones. Como em
um diagrama de seqüência, as flechas indicam as mensagens enviadas dentro de um caso de uso.
Sendo que neste tipo de diagrama a seqüência é indicada pela numeração das mensagens.
Os objetos que interagem por meio de mensagens aparecem como caixas padrões na UML,
com cada uma delas portando o nome de um objeto. Na Figura 19 observa-se que o nome de cada
objeto tem forma nomeDoObjeto:NomeDaClasse, no qual o sublinhado enfatiza que se trata de
instâncias, e não classes. Em um diagrama de colaboração, cada objeto é identificado com o nome
que os outros objetos utilizam para enviar-lhe uma mensagem, uma vez que os objetos não têm
realmente os seus próprios nomes. Deste modo, um objeto destinatário adota o nome da variável no
objeto remetente que detém o identificador do objeto destinatário (PAGE-JONES, 2001).
36
Figura 19: Diagrama de colaboração. Fonte: André & Jales (2003).
3.3.8. Diagrama de Componentes
Silva (2001), menciona que o diagrama de componentes representa os componentes que farão
parte dos sistemas em construção, demonstrando as dependências entre os componentes. Todo o
sistema orientado a objetos terá, dependendo do tamanho, dezenas de componentes que em
conjunto darão sentido a todos os processos do sistema, sendo que os diagramas representam os
aspectos físicos de sistemas orientados a objetos.
Diagramas de componentes são empregados para a modelagem da visão estática de
implementação de um sistema. Isso envolve a modelagem de itens físicos que residem em um nó,
como executáveis, bibliotecas, tabelas, arquivos e documentos. Os diagramas de componentes são
essencialmente diagramas de classes que focalizam os componentes de um sistema. Assim eles não
se tornam só importante para visualizar, especificar e documentar sistemas baseados a
componentes, mas também para elaboração de sistemas executáveis por meio de engenharia de
produção e reserva (BOOCH et al. 2000).
Um diagrama de componentes mostra os vários componentes em um sistema e suas
dependências, freqüentemente o componente representa um modulo físico do código. As
dependências entre componentes mostram como mudanças nos componentes podem influenciar
diretamente em alterações de outros componentes relacionados (FOWLER & SCOOT, 2000).
Com a UML, os diagramas de componentes são empregados para melhor visualizar o
aspecto estático desses componentes físicos e seus relacionamentos desta forma usados para
especificar detalhes que fazem parte do diagrama, conforme mostra a Figura 20.
37
Figura 20: Diagrama de componentes. Fonte: Franco & Santos (2003).
3.3.9. Diagrama de Implantação
O foco principal desse diagrama são os desenvolvedores do sistema. Esse diagrama destina-
se a profissionais que devem estar preocupados com hardware e o software que esta sendo
construído, destacando-se principalmente a compatibilidade entre os dois. Pois esse diagrama
representa a configuração e a arquitetura de um sistema em que estarão ligados seus respectivos
componentes, sua abrangência é a visão estática de implantação de um sistema, envolvendo a
modelagem da topologia de hardware em que o sistema será executado (SILVA, 2001).
De acordo com Booch et al. 2000, estes diagramas não são importantes somente para
visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribuídos, mas
também para o gerenciamento de sistemas executáveis por meio de engenharia reversa.
Um diagrama de implantação mostra um conjunto de nós e seus relacionamentos. Usa-se o
diagrama respectivo para ilustrar a visão estática da implantação da arquitetura (BOOCH et al.
2000).
38
Figura 21: Diagrama de utilização. Fonte: André & Jales (2003).
3.4. Mecanismo de extensão da UML.
Os mecanismos de extensão permitem que aconteça a ampliação da linguagem de maneira
controlada, podendo ser estendida ou adaptada para um método especifico. De acordo com o OMG
(2003), esses mecanismos são elementos de modelagem que permitem um tratamento visual
especializado e definem como criar novas semânticas. A UML dispõe de um conjunto de elementos
e conceitos de modelagem, que foram cuidadosamente definidos para atender aos projetos de
software. Os três mecanismos de extensão podem ser usados em conjunto ou separadamente para
representar novos elementos de modelagem com novas características e notação própria. Esses
mecanismos ainda possibilitam a adaptação a novas tecnologias, porém é importante fazê-la
controladamente para que ao utilizar essas extensões se permaneça fiel ao propósito da UML, a
comunicação de informações. Esses mecanismos incluem as seguintes características: estereótipos,
valores atribuídos, restrições.
3.4.1. Estereótipos
Um estereótipo amplia o vocábulo da UML que permite criações de blocos de construção que
são derivados dos já existentes, específicos a determinados problemas. Podendo especificar
adicionalmente restrições e marcas com valor que serão aplicadas às suas instâncias, usado para
especificar diferenças de utilização ou de sentido entre dois elementos com uma estrutura
semelhante (SALM, 2003).
39
Conforme Albir (1998), os estereótipos devem obedecer às seguintes regras (Tabela 2):
⇒ devem ser limitados por elemento de modelagem;
⇒ devem ser uma subclasse da existente na UML;
⇒ devem possuir a mesma forma ou característica (atributos e operações) da sua classe
original no metamodelo. Isto é, este herda as características da classe-base através de
um relacionamento do tipo herança; e
⇒ devem possuir um propósito diferenciado da classe original, propósito este que deverá
incluir novas propriedades (tagged value e constraint).
Tabela 2: Exemplos de estereótipos. Nome Aplicação Semântica
<<actor>> Class Esta classe define um conjunto de objetos externos que irão interagir com o sistema
<<becomes>> Dependência
A dependência é entre a instância de origem e a instância de destino. A dependência especifica que instâncias de origem e destino em certo momento se fundem em uma só
<<copy>> Dependência
A dependência é entre a instância de origem e a instância de destino. A de destino é uma cópia fiel da de origem no momento do relacionamento de dependência
3.4.2. Valores Atribuídos
São propriedades de elementos, representando informações sobre o modelo e não sobre o
sistema que esta sendo modelado. Os valores atribuídos podem ser colocados dentro de uma
seqüência de caracteres inclui um nome (a etiqueta), um separador (o símbolo), e um valor
(atributo), essencialmente define regras ou condições para diversos relacionamentos entre
elementos de um diagrama na UML. A regra para o uso de valores atribuídos é (SALM, 2003): {tag
= “valor”}.
40
3.4.3. Restrições
Pode-se adicionar uma nova semântica ou modificar as regras existentes. Uma restrição
especifica condições que devem ser mantidas como verdadeiras para que o modelo seja bem-
formado. Porém, para a definição das regras, é utilizada a linguagem textual (Booch et al., 2000).
4. PROCESSO DE DESENVOLVIMENTO.
Segundo Larman (2000), se encontram muitos casos de fracassos em projetos de
desenvolvimentos de software. Um estudo mostra que 31% dos projetos de software nunca são
completados, esse se torna um dos motivos principais pelo qual não se pode simplesmente ir direto
a programação de um sistema, a preocupação com o processo de análise e desenvolvimento vem se
tornando fundamental para o sucesso de muitos projetos.
O processo de desenvolvimento de software é um conjunto de passos parcialmente ordenados,
usados para se atingir um objetivo. Este objetivo está associado a um ou mais resultados concretos
finais, que são os produtos de sua execução. Esta seção descreve tópicos importantes a serem
seguidos e os principais elementos envolvidos no processo de desenvolvimento.
4.1. Processos de Software
Na área de engenharia de software, processos podem ser definidos como desenvolvimentos,
manutenção, aquisição e contratação. Em um processo de desenvolvimento de software, a parte
inicial para a arquitetura do processo é a escolha de um modelo de ciclo de vida (PAULA, 2001).
O ciclo de vida de um sistema é a definição dos passos que transformam a idéia inicial em um
produto final. Segundo Paula (2001), existem sete tipos principais de ciclos de vida para um
software, sendo eles: (i) codifica ou remenda, (ii) cascata, (iii) sashimi, (iv) espiral, (v)
prototipagem evolutiva, (vi) entrega por estágios e (vii) entrega evolutiva.
41
Além desses processos de desenvolvimento, com o surgimento da UML alguns processos
foram definidos, tal como, o Rational Unified Process (RUP), que é apresentado na seção 5.1.1,
sendo ele escolhido como base integração com o diagrama proposto devido proximidade com a
UML. No entanto, vale ressaltar que, como a UML é independente de processo, este pode ser
utilizado por vários processos da engenharia de software.
4.1.1. RUP – Rational Unifed Process
O RUP tem como sua principal meta permitir a produção de software de alta qualidade e de
maneira que atenda às necessidades do usuário final de acordo com o planejamento e orçamentos
previstos. O Rational Unified Process captura algumas das melhores práticas de desenvolvimento
de software, adaptando-as a uma ampla variedade de projetos. Em relação ao gerenciamento, RUP
proporciona um procedimento disciplinado nas tarefas e responsabilidades no sistema em
desenvolvimento (BOOCH et al. 2000).
RUP se fundamenta em uma arquitetura de processos simples que podem proporcionar uma
base comum e ainda acomodar várias situações, se tornando um processo configurável. A avaliação
da qualidade é inserida no processo, em todas as atividades, envolvendo todos os componentes da
equipe. O gerenciamento de risco também acontece no RUP, de forma que os riscos para o sucesso
do projeto são identificados e atacados no início para que se tenha tempo suficiente para uma reação
adequada (BOOCH et al. 2000).
O Rational Unified Process emprega a técnica de orientação a objetos, baseando-se nos
conceitos de classe, objetos e relacionamentos, utilizando a UML como uma notação comum
(BOOCH et al. 2000).
A estrutura do RUP está dividida em fases, workflows e iterações, conforme apresenta a
Figura 22.
42
Figura 22: O ciclo de vida de desenvolvimento de um software no RUP. Fonte: Booch et al. (2000).
4.1.1.1. Fase
“Uma fase é o período de tempo entre dois importantes marcos de progresso do processo em
que um conjunto bem-definido de objetivos é alcançado, artefatos são concluídos e decisões são
tomadas em relação à passagem para a fase seguinte”, assim Booch et al. (2000), define fase, e
conforme sua definição o RUP apresenta quatro fases: concepção, elaboração, construção e
transição.
Wor
kFlo
w
Fases
Iteração
43
4.1.1.2. Concepção
Nesta fase se estabelece o caso a ser desenvolvido e delimita-se o escopo do projeto. Durante
a concepção é comum se criar um protótipo executável que servirá de teste para o sistema,
mostrando a programação dos principais tópicos abordados pelo cliente. No final da fase de
concepção se examina os objetivos do projeto para se tomar a decisão referente a viabilidade de
continuidade do projeto (BOOCH et al. 2000).
De acordo com Duran (2003), a fase de concepção na elaboração de um sistema tem como
objetivos principais:
⇒ Delimitar o escopo do projeto;
⇒ Definir os produtos a serem entregues e os critérios de aceitação;
⇒ Identificar e priorizar os casos de uso (seção 4.3.1) de maior risco;
⇒ Avaliar uma arquitetura candidata para o desenvolvimento;
⇒ Estimar custo e prazo iniciais para todo o projeto;
⇒ Identificar riscos potenciais;
⇒ Preparar o ambiente para o trabalho;
⇒ Customizar o processo para o projeto.
4.1.1.3. Elaboração
A criação de metas ou requisitos é utilizada para obter o domínio do problema a ser
desenvolvido é fundamental nesta fase de desenvolvimento, com o estabelecimento de uma
arquitetura sólida e um plano de projeto bem estruturado acontece a eliminação dos elementos de
mais alto risco do sistema, logo, para se obter garantia de sucesso nesta fase, é recomendado que a
participação de todos os interessados no sistema seja intensiva (BOOCH et al. 2000).
Desta forma, os principais objetivos na fase de elaboração de acordo com Duran (2003), é
dividido em:
⇒ Definir os requisitos e planos de forma detalhada;
44
⇒ Garantir que os requisitos e planos estejam estáveis;
⇒ Estabelecer uma arquitetura de software estável;
⇒ Garantir que os riscos arquiteturais estejam eliminados;
⇒ Garantir com que os demais riscos estejam controlados;
⇒ Determinar uma linha de base arquitetural a partir de cenários significativos;
⇒ Refinar as estimativas de custo e prazo do projeto;
⇒ Manter o ambiente para o trabalho.
4.1.1.4. Construção
Segundo Duran (2003), o objetivo da fase de construção é refinar os requisitos restantes
tentando reduzir os riscos e completar o desenvolvimento com base na arquitetura estabelecida.
Durante a fase de construção acontece o desenvolvimento, o objetivo desse processo é a
reduzir os riscos. Estes riscos geralmente acontecem porque os casos mais difíceis são deixados
para o final do projeto. Nesta fase respectivamente acontece os testes e interações do sistema, sendo
que tarefas como interação são extremamente extensas demorando sempre mais que o previsto pela
equipe de desenvolvimento (FOWLER & SCOTT, 2000).
A aceitação do sistema pelo cliente também acontece nesta fase, analisando assim se o
software está pronto, verificando se as interfaces estão em harmonia e se os usuários estão
relativamente prontos para uso do sistema (BOOCH et al. 2000).
Desta modo, conforme Duran (2003) pode-se destacar os seguintes objetivos na fase de
construção:
⇒ Completar as atividades de análise, design, implementação e testes;
⇒ Desenvolver o produto até que fique pronto para a liberação para os usuários;
⇒ Decidir se o produto pode ser implantado;
⇒ Planejar a implantação;
⇒ Minimizar os custos de desenvolvimento;
⇒ Minimizar o desperdício e reestruturação de um trabalho;
45
⇒ Atingir a qualidade desejada;
⇒ Executar as atividades com o máximo de paralelismo possível.
4.1.1.5. Transição
Na fase de transição, os responsáveis pelo desenvolvimento do projeto ficam a disposição do
usuário, pois sempre surgem questões a serem resolvidas, ajustadas ou correções de problemas que
podem ser identificados no uso do sistema. Esta fase é iniciada com uma versão beta do sistema e
logo depois substituída pela nova versão (BOOCH et al. 2000).
A fase de transição tem como objetivo principal, de acordo com Duran (2003):
⇒ Validação final do sistema em relação às necessidades dos usuários;
⇒ Implantação;
⇒ Treinamento;
⇒ Operação paralela em alguns casos de substituição de sistemas legados;
⇒ Ajuste (tuning), otimização e correção de erros;
⇒ Coleta de dados sobre aceitação final do produto;
⇒ Coleta das métricas do projeto e avaliação da rentabilidade do projeto;
⇒ Coleta das lições aprendidas e encerramento do projeto.
4.1.1.6. Iterações
É um conjunto distinto de atividades com um plano de linha de base e um critério de
avaliação que resulta em uma versão, interna ou externa. Cada iteração passa pelos vários fluxos de
trabalho do processo, embora com uma ênfase diferente em cada um deles (BOOCH et al. 2000).
Uma iteração representa um ciclo completo de desenvolvimento, desde a captação de
requisitos na análise até a implementação e a realização de testes, resultando na versão de um
projeto executável.
46
4.1.1.7. Workflow
O RUP tem nove fluxos de trabalho de processo, que são a evolução do sistema, deste modo
são eles segundo Duran (2003):
⇒ Modelagem de negócio: considera-se os processos referentes ao contexto do negócio
no qual o software irá operar, descrevendo a estrutura e a dinâmica da empresa.
⇒ Requisitos: englobam as atividades de identificação, especificação e gerenciamento de
requisitos.
⇒ Análise e projeto: descreve as várias visões da arquitetura, dentre elas visão lógica,
visão de processo, visão de implementação, visão de implantação e visão de casos de
uso.
⇒ Implementação: considera-se o desenvolvimento do software, testes de unidade e
integração.
⇒ Teste: abrangem as atividades de definição dos casos de teste, os procedimentos e as
medidas para acompanhamento dos erros.
⇒ Implantação: abrange as diretrizes para implantação do software.
⇒ Gerenciamento da configuração: controla as modificações feitas no sistema mantendo
a integridade dos artefatos do projeto.
⇒ Gerenciamento de projeto: descreve as estratégias para a condução gerencial do
projeto, incluindo as atividades de gestão de riscos, supervisão e acompanhamento.
⇒ Ambiente: abrange principalmente a infra-estrutura necessária para o desenvolvimento
do sistema e a customização do processo para projeto em desenvolvimento.
III - DESENVOLVIMENTO
Este capítulo busca apresentar uma proposta de diagrama para representar a especificação de
sistemas quando a ferramenta de implementação for baseada em linha do tempo. Além disso, é
apresentada a integração do diagrama em um processo de desenvolvimento.
As notações do diagrama são descritas no decorrer deste capítulo, mostrando como cada
representação deve acontecer juntamente com as técnicas necessárias para sua construção. Além
disso, é abordada a integração do diagrama em uma ferramenta CASE para demonstrar a
funcionalidade e aplicabilidade do diagrama, para que se possa comprovar de uma melhor forma a
sua viabilidade.
Estudos de caso foram desenvolvidos visando demonstrar a relação entre o diagrama proposto
e a UML, bem como, permitir ilustrar o uso do diagrama em diferentes tipos de aplicações.
O diagrama proposto para ser utilizado nas fases de concepção e elaboração de um processo
de desenvolvimento, tendo como principais objetivos:
⇒ Viabilizar a prototipação da interface do sistema utilizando o conceito de ferramentas
de autoria baseadas em linha do tempo.
⇒ Documentar a integração entre as diferentes linguagens de programação, ou seja, a
ferramenta de autoria e outra linguagem utilizada para, por exemplo, acesso a banco de
dados.
⇒ Mapear a navegação entre as diferentes cenas (telas) do sistema.
⇒ Auxiliar na documentação geral de um sistema baseado em linha do tempo.
1. NOTAÇÃO DO DIAGRAMA PROPOSTO
A seção a seguir aborda a definição dos elementos do diagrama, retomando os conceitos
básicos referentes aos mecanismos de extensão da UML. Também estão apresentadas as regras para
construção do diagrama proposto.
48
1.1. Estereótipos
Como já mencionado na sessão 3.4.1 (Capítulo II) os estereótipos ampliam o vocabulário da
UML, permitindo criações baseadas em derivados já existentes, específicos a determinados
problemas.
O estereótipo tem a indicação de sua classe base e, opcionalmente, uma representação gráfica
(ícone) correspondente. A classe base de um estereótipo é uma classe do metamodelo UML tal
como Class, Association ou GUIelement. Ele pode ser um subtipo de um ou mais estereótipos
existentes. Adicionalmente, o estereótipo pode adicionar as suas próprias restrições, uma lista de
marcas com valores (SILVA, 2001).
Um estereótipo é um metatipo, ou seja, um tipo que descreve tipo. Definindo novos tipos de
elementos assim estendendo a UML. O nome do estereótipo é representado entre caracteres ‘<<’ e
‘>>’, sendo campo obrigatório, apenas o nome do metatipo, as notas, instruções de uso, e a
coordenada de localização x e y não são obrigatórias para criação do estereótipo. Será utilizado tipo
base para especificação do metamodelo que será apresentado junto com a notação do diagrama
(SILVA, 2001).
1.1.1. Tag’s
Cada elemento em UML, segundo Silva & Videira (2001), tem um conjunto de propriedades.
Logo, os estereótipos permitem adicionar novos elementos a UML e as tag’s permitem adicionar
novas propriedades aos elementos, quer sejam elementos já existentes ou elementos definidos em
novos estereótipos.
As tag’s possuem nome, descrição, valores com listas de possibilidades, sendo elas separadas
por “|” (barras), exemplo: “true|false”.
49
1.1.2. Constraint
Todos os elementos da UML têm necessidade de uma determinada semântica. As constraints
permitem adicionar ou alterar a semântica de um metamodelo, tendo ele ou não semântica pré-
determinada. A condição pode ser especificada numa linguagem formal (Object Constraint
Language) ou informal (texto especificado em português) (SILVA, 2001).
Uma restrição permite especificar condições que devem ser válidas para que o modelo seja
bem definido.
1.2. Notação
Conforme discutido na seção 1.4 (Capítulo II), o Flash foi selecionado como “ferramenta
referência” para elaboração do diagrama, devido ao potencial da linguagem ActionScript embutida
na ferramenta. Além disso, foi considerada a proposta apresentada por Muller (2001) como base
para os elementos contidos nesta seção. Para melhor compreensão da notação será utilizado um
padrão na apresentação do conteúdo dos elementos. Assim, a notação proposta para cada elemento a
ser representado no diagrama consiste em:
Ícone representativo: o ícone que representará o elemento.
Descrição: este campo contém o significado do elemento. Classe base: informar a classe relacionada ao elemento. Origem: caso o elemento seja “reaproveitado” de algum outro diagrama, este item informa sua origem. Tag: se existir tags, deve ser citado quais são elas e o que elas representam. Constraint: se o elemento possuir constraint este item o especifica.
Descrição: O filme representa a base principal em qualquer aplicação SBLT, é a interface para o desenvolvimento de uma aplicação. Ele é o primeiro elemento a ser inserido no diagrama. Classe base: GUIElement. Origem: proposto em Muller(2001). Tag: não possui. Constraint: não possui.
Filme
50
Descrição: A cena é utilizada para organização do filme, nela serão criadas as animações ou estarão dispostos os objetos, variáveis e quadros-chave que farão parte do filme. Classe base: GUIElement. Origem: proposto em Muller(2001). Tag: Descrição: breve descrição do conteúdo da cena. Constraint: a cena deve ser inserida dentro do filme.
Descrição: O símbolo representa níveis de especificação que a cena ou objeto possui, no caso da cena existem mais quadros-chave importantes além do principal, no caso dos objetos pode-se representar uma animação ou outras representações contidas dentro do objeto. Conseqüentemente, este objeto terá um outro diagrama específico para apresentar o conteúdo de cada elemento. Classe base: GUIElement. Origem: Diagrama SBLT. Tag: Nível: nível de especificação do elemento. Constraint: não possui.
Descrição: O símbolo indica que o elemento possui repetição, ou seja, pode aparecer várias vezes durante a montagem do diagrama. Os elementos podem ter propriedades diferentes, mas ter o mesmo comportamento, neste caso é utilizada esta representação para que não seja necessário fazer várias diagramações para elementos com mesmo comportamento. Classe base: GUIElement. Origem: Diagrama SBLT. Tag: Nível: nível de especificação que o elemento representará, este campo deve numerar os objetos por grupos de repetição. Quantidade: números de elementos que se repetem. Constraint: não possui.
Descrição: O conjunto de quadros formam a animação, logo o quadro-chave é a localização do início ou fim de uma animação, onde se encontra a figura ou imagem do movimento. Os quadros podem algumas vezes aparecer sem imagens relacionadas apenas sendo utilizados para actions específicos. Classe base: GUIElement. Origem: Diagrama SBLT. Tag: Descrição: descreve-se o que será desenvolvido dentro do quadro-chave. Actions: identifica se o quadro possui action.Valores atribuídos (Sim/Não) Constraint: o quadro-chave deve ser inserido dentro da cena.
Cena
Quadro-chave
Nível
+
*
Repetição
51
Descrição: Os movie ou gráficos são os objetos do sistema. Neste elemento pode ser apresentado o movimento de um objeto. A diferença básica entre o movieclipe e o gráfico, o movie pode conter um outro objeto dentro dele que também tenha movimento, ou seja um movimento dentro do outro. Logo, o gráfico apenas possui um movimento. Outra característica importante que os diferenciam é que o movie pode ter uma variável vinculada a ele. Eles possuem especificações que serão identificas pelos níveis que serão representados durante a construção do diagrama. Classe base: GUIElement. Origem: Diagrama SBLT. Tag: Descrição: se o objeto possuir movimento fazer uma breve explicação como será o seu movimento; Actions: deve apresentar quais ações esse objeto possui; Variável: se o objeto estará vinculado a uma variável (tag existente apenas no movieclip). Valores atribuídos (Sim/Não); Movimento: especifica se o objeto possui movimento ou não. Valores atribuídos (Sim/Não); Imagem: se existe uma imagem vinculada ao objeto e o que representa. Constraint: o elemento deve estar dentro da cena.
Descrição: São símbolos que possuem ações ou comandos de interação através do acionamento do botão. Classe base: GUIElement. Origem: Utilizado em ferramentas de autoria. Tag: Eventos: qual dos eventos do botão acontece à ação (onclick/mousedown/mouseup). Ação: que ação possui o botão. Constraint: o botão deve se inserido dentro da cena, logo pode estar também dentro de qualquer elemento.
Associação Descrição: Representação de comunicação entre cenas,entre entidades externas (como banco de dados ou outros filmes) ou entre objetos do diagrama podendo também representar as entradas e/ou saídas de dados. Classe base: Use Case. Origem: Diagrama de Use Case. Tag: não possui. Constraint: não possui.
Entrada/Saída de dados
Descrição: Representa o nome das variáveis de entrada ou de saída na cena Classe base: GUIElement. Origem: diagrama Custom (textbox). Tag: não possui. Constraint:deve ser inserido dentro do quadro-chave.
Descrição: Essa notação representa a interação de um ator com a cena. E a integração deve ser melhor detalhada no diagrama de use-case. O ator é uma representação genérica, ele não é
Ator
Botão
Clip de filme ou Gráfico
52
especificado na cena, apenas indica que há uma integração entre o usuário e o sistema, esta especificação é detalhada no diagrama de use case. Classe base: Actor. Origem: Diagrama de Use Case Tag: não possui. Constraint: não possui.
Descrição: Interpretador é o meio de comunicação do sistema que contempla a implementação fora da ferramenta de linha do tempo. Classe base: Component. Origem: Diagrama de componente. Tag: não possui. Constraint: não possui.
Descrição: O banco de dados é a representação de uma entidade externa, logo deve ser criado um diagrama para representar as tabelas que serão utilizadas na aplicação. Classe base: GUIElement. Origem: Diagrama SBLT. Tag: Tabela: deve ser colocado o nome da tabela que será acessado no banco de dados. Constraint: não possui.
Quadro 1: Notação do diagrama
1.3. Regras para construção
Esta seção aborda as regras de relacionamento do diagrama proposto, apresentando de forma
sucinta como os estereótipos criados podem estar dispostos dentro do diagrama. Ou seja, relações
existentes entre os elementos.
Inicialmente, acredita-se que os elementos necessários para compor o diagrama estão contidos
dentre as representações apresentadas. Sendo assim, a Figura 23 define os relacionamentos
possíveis entre os diversos elementos.
Banco de Dados
Interpretador
53
Figura 23: Relacionamento entre os elementos do diagrama.
Logo para ser desenvolvido um diagrama bem estruturado, algumas relações devem ser
conhecidas e respeitadas, sendo assim, abaixo são apresentadas estas relações básicas :
Relação 1 : O filme deve ser o primeiro elemento a ser inserido no diagrama, devendo conter
o nome do filme.
Relação 2 : A cena deve ser inserida dentro do filme, não existe limite na quantidade de cenas
existentes. Dentro deste elemento estarão dispostos os outros elementos do diagrama.
Relação 3 : O quadro-chave deve ser inserido dentro da cena, pois cena é composta de vários
quadros. O quadro-chave pode possuir imagens para formar o desenho ou movimento do filme, bem
como possuir actions para controle de dados.
Relação 4: O clip de filme deve ser colocado dentro do quadro-chave, ele também pode
possuir um outro clip de filme dentro dele, representando um movimento dentro do outro, não
existe limites na quantidade existentes, a cena pode possuir quantos clips de filme forem
necessários.
Cena
Filme
Quadro Chave
Interpretador
Ator
Banco de Dados
1 *
1
1 *
0 * 1 *
1 *
1 * 0 *
0 1
1
1
0 *
Quadro
Objeto
54
Relação 5: O nível de especificação representa que existem outros quadros a serem
especificados, ou seja, caso a cena ou elemento possuir mais quadros-chave que o principal.
Juntamente com o símbolo estará o número identificando o nível da especificação. Por exemplo, se
o filme possui duas cenas e estas possuírem mais de um quadro-chave a cena 1 terá como
numeração 1.1 e a cena 2, 1.2. O nível deve estar dentro do elemento que estará sendo especificado.
Esta relação vale também para os objetos, pois os clips de filme possuem quadros dentro dele.
Relação 6: Outra forma de especificação de objetos é a repetição, esta representa os objetos
que são reaproveitados, ou seja, que possuem as mesmas propriedades. Por exemplo, clip de filme
que possuem o mesmo movimento, não há necessidade de fazer uma especificação para cada um,
identifica-o como repetição e cria-se apenas um diagrama para representá-los.
Relação 7: O botão pode ser inserido dentro de qualquer elemento do diagrama desde que
este elemento esteja dentro do filme.
Relação 8: O elemento ator, que representa a interação do usuário com o sistema, deve ser
inserido dentro da cena. A existência deste elemento indica que o use-case possui um cenário
especificando os comportamentos relacionados com a cena.
Relação 9: O interpretador representa o arquivo que faz a comunicação com qualquer
implementação fora da ferramenta de linha de tempo, este arquivo vai conter comandos para envio
de dados para o sistema. Pode ser um arquivo php, asp, C++, entre outros.
Relação 10: As associações indicam comunicações entre os elementos que fazem parte do
diagrama, as setas indicam o caminho que os dados devem percorrer.
Relação 11: O banco de dados indica a tabela que será feita à comunicação, logo deve ser
criado um diagrama E-R.
55
1.4. Visão Geral do Diagrama Proposto
De maneira geral, o diagrama apresenta uma visão genérica da organização dos elementos
para construção do diagrama, ou seja, não se refere a nenhuma aplicação específica. Este formato
está apresentado na Figura 24. Para esta representação a leitura efetuada a partir do diagrama
representativo de um sistema geral é a seguinte:
Figura 24: Detalhamento do filme.
O filme é constituído por 3 cenas das quais cada uma delas possui um nome e o seu quadro
chave inicial, que indica o primeiro quadro a ser executado no sistema.
A cena 1 possui o relacionamento com o usuário (indicado pelo ator), um atributo de cena e
um objeto que está representado como um botão. A cena 2 possui, além do seu quadro chave inicial,
outros quadros (indicados pelo no e o símbolo ) que depois serão detalhados na seqüência do
diagrama, possuindo ainda um objeto, os atributo de cena e ainda a interação com o usuário. Logo,
a cena 3 é composta apenas por atributos de cena.
+
Filme.swf
Cena 1
Atributo 1 da cena
Cena 2
Atributo 1 da cena Atributo 2 da cena
Cena 3
Atributo 1 da cena
+ 1.1
Documento php
56
As setas indicadas entre as cenas representam a navegação que pode acontecer entre elas,
logo, as setas que se comunicam com a entidade externa representam o fluxo de entrada e saída de
dados do sistema, passando pelo interpretador, onde acontece o acesso à entidade respectiva no
banco de dados.
1.4.1. Especificação da Cena
Deve-se considerar que uma cena (conforme apresentado na Figura 24) pode conter mais de
um quadro-chave. Portanto, propõe-se que nestes casos (indicados pelo símbolo ) se construa um
novo diagrama detalhando os quadros-chave da cena. Sendo assim, a leitura do detalhamento da
cena 2, apresentada na Figura 25, ocorre da seguinte forma:
A cena 2 contém três quadros-chave, onde o primeiro é o mesmo especificado na Figura 25,
sendo que nele contém atributos de cena, nos outros quadros podem ser representados como
mensagens de erro ou retorno de consulta de dados. Sendo que o primeiro quadro contém um objeto
associado, que na figura está representada por um botão.
Figura 25: Detalhamento da Cena 2.
+
Filme.swf
Cena 2
Atributo da cena Atributo da cena Atributo 1 da cena Atributo 2 da cena
57
2. CONFIGURAÇÃO DE FERRAMENTA CASE
CASE (Computer-Aided Software Engineering) significa engenharia de software com o
auxílio de computador, a ferramenta refere-se a um tipo de programa utilizado para apoiar
atividades de processos de software. Todos os métodos atualmente que utilizam tecnologia CASE,
possuem editores para as notações utilizadas, módulos de análise que verificam o modelo de acordo
com as regras do método e geradores de relatórios para ajudar na criação da documentação de
sistemas. As ferramentas CASE podem também incluir um gerador de códigos que,
automaticamente, origina código-fonte a partir do modelo de sistemas e algumas orientações de
processo (SOMERVILLE, 2003).
Para facilitar a compreensão e utilização dos elementos, a ferramenta CASE Enterprise
Architect foi utilizada. Isto se deve unicamente ao fato de que este software encontra-se licenciado
na Universidade sendo que esta ferramenta permite a definição de novos estereótipos e tem custo
relativamente acessível1.
Enterprise Architect é uma ferramenta CASE, muito utilizada no auxílio a desenvolvimento
de aplicações, desenvolvida pela empresa Sparx Systems. A versão utilizada para criação do
diagrama proposto é a 3.51.618, de 01 de outubro de 2002 possuindo como principais
funcionalidades:
⇒ Criação de elementos da linguagem UML;
⇒ Disposição dos elementos em diagramas e pacotes;
⇒ Conexão entre elementos;
⇒ Documentação dos elementos criados;
⇒ Geração de código para compiladores de software; e
⇒ Engenharia reversa de código escrito em várias linguagens.
1 O custo de uma licença com todas funcionalidades (Enterprise Edition) é de US$ 160,00 de acordo com o
website da empresa, disponível em http://www.sparxsystems.com.au, 2003.
58
Esta ferramenta também serve para gerência de projetos, que permite descrever os ciclos de
desenvolvimento de um projeto, além de prover recursos de rastreamento de informações desde a
concepção inicial até os vários aspectos do ciclo de vida destes projetos, como testes, manutenção e
controle de versões (TUTORIAL ENTERPRISE ARCHITECT, 2003).
A ferramenta Enterprise Architect permite a adição de novos estereótipos através de um
esquema aberto, no formato XML (Extensible Meta-Language). Neste arquivo é possível configurar
todas as propriedades que os novos objetos podem receber. As tags (valores etiquetados) criam
propriedades e, opcionalmente, valores de atribuição a estas. As constraints (restrições) limitam o
escopo de utilização dos estereótipos, como pré-condições de utilização, por exemplo.
Os estereótipos propostos neste trabalho estão descritos em um arquivo XML no esquema do
Enterprise Architect, com o mesmo conteúdo mostrado na notação do diagrama, como mostra o
quadro 2.
<?xml version="1.0" encoding="UTF-8"?> <UMLProfile> <Documentation id="TimeProfile" name="UML Profile para Sistemas Baseados em Linha do Tempo" version="1" notes="Um conjunto de estereotipos para Modelagem de sistemas baseados em Linha do Tempo"/> <Content> <!-- Lista de estereotipos que serao usados--> <Stereotypes> <!-- <<Filme>> --> <Stereotype name="Filme" notes="" cx="172" cy="178" metafile="filme.emf" > <AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> </TaggedValues> <Constraints> <Constraint name="" type="" notes=""/> </Constraints> </Stereotype> <!-- <<Cena>> --> <Stereotype name="Cena" notes="" cx="132" cy="138" metafile="cena.emf"> <AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Descricao" description="" /> </TaggedValues> <Constraints>
<Constraint name="constraint" type="pre" notes="A cena deve ser inserida dentro de um filme" />
</Constraints> </Stereotype> <!-- <<Quadro-chave>> -->
<Stereotype name="Quadro-chave" notes="" cx="105" cy="105" metafile="quadro.emf">
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Descricao" description=" " /> <Tag name="Actions" description=" " />
59
</TaggedValues> <Constraints>
<Constraint name="constraint1" type="pre" notes="O quadro deve ser inserido dentro da cena" />
</Constraints> </Stereotype> <!-- <<MovieClip>> -->
<Stereotype name="Clip de filme" notes="Representa um Movie Clip" cx="28" cy="28" metafile="movie.emf">
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Descricao" description=" " /> <Tag name="Actions" description=" " /> <Tag name="Variavel" description=" " />
<Tag name="Movimento" description="" values="Sim | Não" default="Não" />
<Tag name="Imagem" description="" /> </TaggedValues> <Constraints>
<Constraint name="constraint3" type="pre" notes="O MovieClip devera ser inserido dentro da cena" />
</Constraints> </Stereotype> <!-- <<Especificacao>> -->
<Stereotype name="Nivel" notes="Representa um nivel de especificacao" cx="10" cy="10" metafile="nivel2.emf" >
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Nivel" description=" " /> </TaggedValues> <Constraints> <Constraint name="" type="pre" notes="" /> </Constraints> </Stereotype> <!-- <<Especificacao>> -->
<Stereotype name="Repeticao" notes="Representa que um elemento se repete" cx="10" cy="10" metafile="repetir1.emf" >
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Nivel" description=" " /> </TaggedValues> <Constraints> <Constraint name="" type="pre" notes="" /> </Constraints> </Stereotype> <!-- <<Grafic>> --> <Stereotype name="Grafico" notes="Representa um Grafico" cx="28" cy="28" > <AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Especificacao" description=" " /> <Tag name="Actions" description=" " />
<Tag name="Movimento" description="" values="Sim | Não" default="Não" />
<Tag name="Imagem" description="" /> </TaggedValues> <Constraints>
<Constraint name="constraint4" type="pre" notes="O Grafico devera ser inserido dentro da cena"/>
</Constraints> </Stereotype> <!-- <<Button>> -->
<Stereotype name="Botao" notes="Representa um Botao" cx="76" cy="20" metafile="but.emf" >
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues>
60
<Tag name="Eventos" description="" values="Onclick | Mousedown | Mouseup | " default="Onclick" />
<Tag name="Acao" description="" /> </TaggedValues> <Constraints>
<Constraint name="constraint3" type="pre" notes="O Botao deve ser inserido dentro da cena"/>
</Constraints> </Stereotype> <!-- <<Banco>> -->
<Stereotype name="Banco" notes="Representa o Banco a ser utilizado" cx="60" cy="65" metafile="banco.emf">
<AppliesTo> <Apply type="GUIElement"/> </AppliesTo> <TaggedValues> <Tag name="Tabela" description="" /> </TaggedValues> <Constraints> <Constraint name="" type="" notes=""/> </Constraints> </Stereotype> </Stereotypes> </Content> </UMLProfile>
Quadro 2: Arquivo XML
Uma vez definidos os estereótipos no arquivo XML, estes devem ser incorporados ao
Enterprise Architect. Portanto, é importante que os meta-arquivos (imagens no formato EMF)
estejam no mesmo diretório do arquivo a ser importado e que exista um projeto em execução.
O processo de importação é realizado através da aba Resource View do componente
Workspace (Figura 26), deve-se acessar com o botão direito em UML Profiles, selecionar a opção
Import Profile (Figura 27) e apontar o diálogo de abertura de arquivo para o documento XML.
Figura 26: Interface do Enterprise Architect.
61
Figura 27: Exemplo de importação do arquivo XML.
Tendo-se o processo de importação concluído com sucesso, tem-se os elementos disponíveis
na barra UML Profile em Resouce View, sendo que para acessá-los deve-se clicar no elemento
desejado e arrastar para onde se deseja criar o diagrama. As tags dos elementos aparecem na barra
Properties quando os mesmos estão selecionados, como apresentado na Figura 28.
Os diagramas fornecem o ambiente principal de trabalho da ferramenta e são carregados
quando se clica em seus respectivos ícones do Project Explorer (Figura 28).
Figura 28: Exemplo dos estereótipos já importados na ferramenta.
62
3. INTEGRAÇÃO DIAGRAMA PROPOSTO COM PROCESSO DE DESENVOLVIMENTO DE REFERÊNCIA
Inicialmente, considera-se adequado utilizar o processo de desenvolvimento RUP como
referência, pois, o mesmo utiliza-se dos diagramas propostos pela UML e consiste em um processo
de desenvolvimento iterativo, característica esta importante para dar flexibilidade à proposta do
diagrama. Sendo assim, a Figura 29 apresenta os pontos de integração que o diagrama deve
proporcionar nas fases de concepção e elaboração do RUP, principalmente voltado para a definição
de requisitos, análise e projeto.
Figura 29: Pontos de integração no RUP. Fonte: Booch et al. (2000).
Considerando o RUP como processo de desenvolvimento adotado como modelo para integrar
o diagrama proposto, inicialmente deve-se desenvolver o diagrama de casos de uso para definir os
requisitos do sistema. Paralelamente ao desenvolvimento do diagrama de casos de uso deve-se
iniciar a elaboração do diagrama proposto, focando no projeto das cenas envolvidas e dos campos
(atributos) que compõem cada cena. A Figura 30 ilustra a integração entre os diagramas.
Figura 30: Integração entre os diagramas.
63
Para facilitar o entendimento do projeto do sistema, sugere-se ainda que se faça também a
relação das cenas com os casos de uso, ou seja, na descrição dos cenários de cada caso de uso
referenciar a cena associada, conforme exemplo ilustrado na Figura 31.
Orientador pedagógico
Cadastra projeto de trabalho
Cenário principal: 1) Orientador pedagógico informa dados do projeto (CENA 1). 2) Sistema verifica se projeto não se encontra cadastrado. 3) Sistema inclui projeto. Cenário Alternativo: Se no passo 2, nome do projeto encontra-se cadastrado apresenta Mensagem “Nome de projeto já cadastrado”. (CENA 1 – quadro-chave 2)
Figura 31: Exemplo de integração Caso de Uso – Cena
A idéia apresentada nesta seção pode ser melhor visualizada na especificação dos estudos de
caso, na seção 4.
4. ESTUDO DE CASO
Para avaliar a consistência do diagrama proposto e verificar a integração deste com o processo
de desenvolvimento de referência adotado, estudos de caso são abordados durante esta seção. Para
tanto, pretende-se desenvolver uma aplicação voltada a auxiliar no gerenciamento de portfólios de
projetos de trabalho, a qual deverá conter a especificação considerando o diagrama e integração
com o processo de desenvolvimento bem como, a sua implementação com a ferramenta Flash.
Outro estudo de caso refere-se à aplicação voltada a web, o website apresenta um projeto de
pesquisa que está sendo desenvolvido pelos alunos do curso de ciência da computação da Univali
com apoio do CNPq (Conselho Nacional de Desenvolvimento Científico e Tecnológico) e a
Secretaria de Educação de Blumenau. Ainda dentro deste mesmo contexto, é apresentada a
especificação através da engenharia reversa de um sistema que está em desenvolvimento no
Laboratório de Soluções de Software, sendo que esta aplicação também é parte do projeto apoiado
pelo CNPq.
64
4.1. Aplicação projeto de trabalho
Pretende-se desenvolver uma aplicação voltada a auxiliar no gerenciamento de portfólios de
projetos de trabalho, a qual deverá conter a especificação considerando o diagrama e integração
com o processo de desenvolvimento, bem como a sua implementação com a ferramenta Flash.
Sendo assim, faz-se necessário definir o termo “projeto de trabalho”. Katz (1994 apud
FLEISCHHAUER, 2002) define um projeto de trabalho como
uma investigação em profundidade de um tópico que vale a pena estudar. A característica
chave de um projeto, para Katz (1994), é o esforço investigativo deliberadamente enfocado
em encontrar respostas, nem sempre corretas, para perguntas sobre um tópico, pois o
importante é aprender mais. Neste aspecto, é necessário ter em conta o que significa
‘investigar’, pois, o tratamento da informação será de acordo com a investigação que se
faça de um tema. Então, investigar é formar conclusões com base em observações próprias,
construir modelos, observar, anotar os achados, explorar, predizer, discutir e dramatizar
(representar) novos conhecimentos.
O Projeto de Trabalho visa uma reestruturação do espaço escolar, transformando em um
espaço de interações bem próximas do mundo real e as suas múltiplas dimensões. O trabalho com
projetos traz uma nova perspectiva para compreender processo de ensino/aprendizagem.
“Aprender” deixa de ser um simples ato de memorização e ensinar não se aplica apenas a repassar
conteúdos prontos. A formação, dos alunos não pode ser pensada apenas como uma atividade
intelectual, mais como um processo global e complexo onde o conhecer e intervir no mundo real
não se encontram desassociados (MAGALI, 2003).
Segundo NIED (2003) as características básicas para o ensino por meio de projetos de
trabalho são:
⇒ Um Projeto de Trabalho é uma atividade intencional, orientada em direção a um
objetivo que dará sentido às várias atividades que serão desenvolvidas pelo grupo. Para
isso os grupos envolvidos traçam planos, usam diversos recursos disponíveis;
65
⇒ Não existe um tempo fixo para o desenvolvimento de um Projeto de Trabalho, o
planejamento do Projeto de Trabalho deve ser flexível, de modo que o tempo e as
condições para desenvolvê-lo sejam sempre reavaliados em função dos objetivos
inicialmente propostos;
⇒ Cada Projeto de Trabalho incorpora as experiências e expectativas do grupo, portanto
seu trabalho não deve ser comparado com outros. O problema que será investigado
surge da necessidade do grupo e está relacionado com as experiências e expectativas
dos sujeitos que esse grupo representa;
⇒ O Projeto de Trabalho deve se desenvolver apoiado na realidade de cada grupo, não há
uma única realidade ou uma única verdade. O caminho escolhido por um grupo é
diferente daqueles escolhidos por outros grupos, desta forma acontece a necessidade de
cada um encontrar a orientação necessária para o percurso;
⇒ Cada grupo tem seu tempo para desenvolvimento de seu Projeto de Trabalho, os
participantes têm ritmos e estilos diferentes;
⇒ O grupo necessita acreditar nas suas potencialidades para que possa refletir, criar,
descobrir, crescer e desenvolver-se na trajetória da construção do seu próprio
conhecimento. Todos podem aprender, inclusive o educador se tornando fundamental a
experiência de cada um apresentada na formulação do problema e no desenvolvimento
do Projeto de Trabalho.
4.1.1. Descrição
Desenvolver uma aplicação que possa ter controle de dados de vários tipos projetos de
trabalho, onde se possa consultar como está se desenvolvendo a aplicação destes e os seus
resultados, bem como criar um banco de dados de projetos em cada escola, permitindo o registro de
idéias inovadoras.
O sistema deve permitir o cadastramento de:
⇒ projetos de trabalho;
⇒ atividades vinculadas aos projetos;
⇒ professores;
66
⇒ turmas.
O sistema deve ainda, apresentar detalhes de projetos aplicados a determinadas turmas e
detalhes de projetos de trabalho agrupados por professores. Por fim apresenta-se uma lista do
projeto de trabalho, relacionando atividades e conceitos trabalhados.
4.1.2. Diagramas
Esta seção apresenta os diagramas de use-case com as especificações dos cenários e o
diagrama SBLT gerados pela ferramenta Enterprise Architect, bem como o diagrama E-R refletindo
a estrutura de banco de dados.
4.1.2.1. Use-Case: Projeto de trabalho
Referente ao estudo de caso “Projeto de trabalho”, identificou-se os seguintes casos de uso da
aplicação, conforme visualizado na Figura 32:
⇒ Cadastra projeto de trabalho;
⇒ Cadastra professor;
⇒ Cadastra turma;
⇒ Cadastra atividade;
Orientador Pedagógico
Cadastra projeto de trabalho
Cadastra professor Cadastra turma
Cadastra ativ idade
Figura 32: Diagrama de use-case do sistema projeto de trabalho.
67
O quadro 3 apresenta a descrição dos cenários dos casos de uso descritos acima.
Cadastra atividade Cenários Cenário principal. 1) Orientador Pedagógico informa dados da atividade (Cena 1 quadro-chave 16) 2) O sistema verifica se a atividade não se encontra cadastrada 3) O sistema inclui a atividade Cenário alternativo. 1) Se no passo 2, a atividade encontra-se cadastrada apresenta mensagem "Atividade já cadastrado" (Cena 1 - quadro chave 24) Cenário alternativo. 2) Se no passo 2, os dados da atividade não forem preenchidos corretamente apresenta mensagem "Campos obrigatórios não preenchidos" (Cena 1 - quadro chave 29) Cadastra professor Cenários Cenário Principal 1) Orientador Pedagógico informa dados do professor (Cena 1 quadro-chave 2) 2) O sistema verifica se o professor não se encontra cadastrado 3) O sistema inclui o professor Cenário Alternativo. 1) Se no passo 1, nome o professor encontra-se cadastrado apresenta mensagem "Professor já cadastrado" (Cena 1 - quadro chave 8) Cenário Alternativo. 2) Se no passo 1, os dados do professor não for preenchido corretamente apresenta mensagem "Campos obrigatórios não preenchidos" (Cena 1 - quadro chave 7) Cadastra projeto de trabalho Cenários Cenário Principal. 1) Orientador Pedagógico informa dados do projeto (Cena 1 quadro-chave 21) 2) O sistema verifica se o projeto não se encontra cadastrado 3) O sistema inclui o projeto Cenário Alternativo. 1) Se no passo 2, nome do projeto encontra-se cadastrado apresenta mensagem "Projeto já cadastrado" (Cena 1 - quadro chave 26) Cenário Alternativo. 2) Se no passo 2, nome os dados do projeto não for preenchido corretamente apresenta mensagem "Campos obrigatórios não preenchidos" (Cena 1 - quadro chave 26) Cadastra turma Cenários Cenário principal. 1) Orientador Pedagógico informa dados da turma (Cena 1 quadro-chave 9) 2) O sistema verifica se a turma não se encontra cadastrada 3) O sistema inclui a turma
68
Cenário alternativo. 1) Se no passo 2, nome a turma encontra-se cadastrada apresenta mensagem "Turma já cadastrado" (Cena 1 - quadro chave 16) Cenário alternativo 2) Se no passo 2, os dados da turma não forem preenchidos corretamente apresenta mensagem "Campos obrigatórios não preenchidos" (Cena 1 - quadro chave 14)
Quadro 3: Descrição dos cenários do projeto de trabalho.
4.1.2.2. SBLT: Projeto de trabalho
A figura 33 apresenta o diagrama proposto para auxiliar na especificação da aplicação
desenvolvida na ferramenta Macromedia Flash.
O diagrama a seguir apresenta um tipo de desenvolvimento onde se tem apenas uma cena com
vários quadros-chave, cada quadro representa uma tela da interface de desenvolvimento da
aplicação.
O anexo apresenta a descrição das tags de cada elemento contido no diagrama.
69
Projeto de trabalho
Cena principal
quadro-chav e 17
Quadro chav e 2
Quadro chav e 1
Projeto
Turma
Professor
Texto explicativo
Nome
excluir
quradro chav e 9
Env iar
Turno
Nome
quadro chav e 16
Enviar
Quadro-chave 21
Nome
Descrição
quadro-chav e 22
Nome da Atividade
Descrição
Lista de professores
env iar
detalhes
Resultados
Lista de turmas
excluirdetalhes
Lista de Atividades
detalhes excluir
Lista de Projetos
detalhes excluir
quadro-chav e 3
quadro-chav e 10
Detalhes de Professores
Detalhes de Turmas
Detalhes de atividades
menu
menu
menu
menu
Detalhes de Projetos
Voltar
Voltar
Voltar
quadro-chav e 5
quadro-chav e 12
quadro-chav e 11
quadro-chave 24
quadro-chave 23
quadro-chav e 18
quadro-chav e 19
quadro-chav e 4
Dados cadastrados com sucesso
Dados cadastrados com sucesso
Dados cadastrados com sucesso
Dados cadastrados com sucesso
Dados excluidos com sucesso
Dados excluidos com sucesso
Dados excluidos com sucesso
Dados excluidos com sucesso
quadro-chav e 7
quadro-chav e 14
quadro-chav e 25
quadro-chav e 20
Campos obrigatórios não preenchidos
Campos obrigatórios não preenchidos
Campos obrigatórios não preenchidos
Campos obrigatórios não preenchidos
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
Voltar
listar_professores.php
Listar turmas.php
Listar ativ idades.
php
Listar projetos.php
MySqlMySql
MySql
MySql
detalha_professores.php
quadro-chav e 6
quadro-chav e 13
O professor não pode ser excluido
A turma não pode ser ser excluida
Voltar
Voltar
Env iar
MySql
lista_detalhes_turma.php
MySql
listar_detalhes_projetos.php
listar_detalhes_ativ idades.php
MySql
MySql
UI Control
quadro-chav e 8
Professor já cadastrado
Voltar
quadro-chav e 15
Turma já cadastrado
Voltar
quadro-chav e 21
Atividade já cadastrada
Voltar
quadro-chav e 26
Projeto já cadastrado
Voltar
Professor Turma
Figura 33: Diagrama SBLT do sistema projeto de trabalho.
70
4.1.2.3. Diagrama E-R: Projeto de trabalho
Esta seção apresenta os relacionamentos e as tabelas disponíveis no sistema projeto de
trabalho.
Figura 34: Diagrama SBLT parcial de projeto de trabalho.
4.1.3. Implementação
Para ilustrar a realização da especificação apresentada, esta seção ilustra parte do diagrama
SBLT (Figura 35) e as tabelas resultantes após a implementação.
71
O diagrama parcial apresenta o cadastramento de projeto, o quadro-chave 21, demonstra a tela
de cadastro de projeto, cuja Figura 36 mostra a tela de implementação resultante do diagrama. O
quadro-chave 22 representa o detalhe do projeto escolhido pelo usuário na lista de projetos,
conforme apresentado na figura 37. A seguir o quadro-chave 26 apresenta uma mensagem do
sistema que é chamada quando o usuário tenta cadastrar um projeto e este já se encontra cadastrado,
representado na Figura 38. Logo o quadro-chave 22 possui a comunicação com a tabela projetos no
momento que o usuário deseja consultar os detalhes do projeto. Esta chamada acontece através de
um arquivo PHP para tratamento dos dados, arquivo este que se encontra listado no quadro 4.
Quadro-chav e 21
Nome
Descrição e Resultados
quadro-chav e 22
Lista de Projetos
detalhes excluir
menuDetalhes de Projetos
Voltar
Env iar
listar_detalhes_projetos.php
MySql
quadro-chav e 26
Projeto já cadastrado
Voltar
Professor Turma
Atividade
Cad Ativ idade
Figura 35: Diagrama SBLT parcial de projeto de trabalho. As Figuras a seguir representam a implementação resultante do diagrama parcial apresentado.
72
Figura 36: Tela de cadastro de projeto.
Figura 37: Tela de detalhes de projeto.
Figura 38: Mensagem do sistema.
73
<?php $conexao = mysql_connect("inf.univali.br","fabricio","**********"); mysql_select_db("fabricio"); $consulta = mysql_query("SELECT nome, detalhes FROM projeto ORDER BY 1"); $n_linhas = mysql_num_rows($consulta); $variaveis = "n=".$n_linhas; //nlinha conta variavel e corre o array ate o numero de linhas existentes for ($j=0; $j < $n_linhas; $j++) { $linha = mysql_fetch_array($consulta); $variaveis .= "&nome$j=".$linha['nome']."&detalhes$j=".$linha['detalhes']; } echo $variaveis; mysql_close($conexao); ?>
Quadro 4: Arquivo PHP que monta a lista detalhes do projeto.
4.2. Projeto Web
Desenvolver uma aplicação que possa ter controle de dados de vários tipos projetos de
trabalho, onde se possa consultar como está se desenvolvendo a aplicação destes e os seus
resultados, bem como criar um banco de dados de projetos em cada escola, permitindo o registro de
idéias inovadoras.
4.2.1. Descrição
A aplicação tem por objetivo principal apresentar o projeto Softvali. Foi desenvolvida um
página web pois as ferramentas de autoria são muito utilizadas neste tipo de aplicação.
O site apresenta como página inicial uma breve introdução sobre o projeto, permitindo
também a exibição das últimas notícias disponibilizadas.
Outros dados disponíveis neste site são o histórico do Softvali e a sua equipe de
desenvolvimento, possuindo também uma opção para contato com a equipe.
74
Os usuários têm a possibilidade de cadastramento de login e senha para terem acesso os
campos que permitem relatar as aplicações de projetos de trabalhos, descrevendo os resultados
destas aplicações. Bem como a possibilidade de enviar perguntas que ficam disponibilizadas para
consultas.
O desenvolvimento desta aplicação utilizou-se da criação de uma cena para cada página
apresentada no sistema, como apresentado no diagrama SBLT.
4.2.2. Diagrama
Esta seção apresenta os diagramas de use-case com as descrições de cenários, juntamente com
os diagramas SBLT e diagrama E-R.
4.2.2.1. Use-case: Softvali
Referente ao sistema web Softvali, identificou-se os seguintes casos de uso da aplicação,
conforme apresentado na Figura 39.
⇒ Cadastro para download
⇒ Relata projetos aplicados
⇒ Cadastra login
⇒ Envia e-mail
⇒ Faz perguntas
75
Usuário
Cadastra para download
Cadastra login
Env ia e-mail
Faz perguntas
Relata projetos aplicados
Figura 39: Diagrama de use-case do sistema Softvali.
O Quadro 5 apresenta a descrição dos cenários dos casos de uso.
Cadastra login Cenários Cenário Principal. 1) O usuário informa nome, função, login e a senha desejadas e a sua confirmação. (Cena cadastro quadro-chave 1) 2) O sistema verifica se o usuário já está cadastrado. 3) O sistema gera um login e apresenta a Mensagem "usuário cadastrado com sucesso" - (Cena download - quadro-chave 5). Cenários Alternativos. 1) Se no passo 2, as senhas fornecidas pelo usuário forem diferentes apresenta-se a Mensagem "Senhas não conferem" (Cena cadastro quadro-chave 2) 2) Se no passo 2, o usuário já estiver cadastrado, o sistema apresenta a Mensagem "Usuário já cadastrado". (Cena cadastro quadro-chave 3) 3) Se no passo 2, o usuário omitir algum dado que seja obrigatório para o cadastro, o sistema apresenta a Mensagem "Campos com omissão de dados". (Cena cadastro quadro-cave 4) Cadastra para download Cenários Cenário Principal. 1) O usuário informa instituição, nome e-mail. (Cena download). 2) O sistema verifica se o usuário não se encontra cadastrado. 3) Sistema inclui o usuário disponibilizando o material para download (Cena download - quadro-chave 3). Cenário Alternativo. Se no passo 2 o usuário preencheu algum dos campos incorretamente ou omitiu dados, apresenta-se a Mensagem "Dados preenchidos com erro" (Cena download - quadro-chave 2).
76
Envia e-mail Cenários Cenário principal. 1) O usuário informa nome, e-mail e a mensagem. (Cena contato quadro-chave 1). 2) O sistema envia os dados para o e-mail do administrador, em seguida apresenta a Mensagem "E-mail enviado com sucesso" (Cena contato quadro-chave 2) Cenário Alternativo. Se no passo 2 houver problemas no envio da mensagem, apresenta-se a Mensagem "Houve problemas de envio. Tente novamente" (Cena contato quadro-chave 3) Faz perguntas Cenários Cenário principal. 1) O usuário faz uma pergunta. Informa também o nome e e-mail. (Cena faq - quadro-chave 1). 3) O sistema inclui os dados no sistema e apresenta a Mensagem "pergunta enviada com sucesso" - (Cena faq - quadro-chave 2). Cenário Alternativo . 1) Se no passo 2 houver algum problema com o envio dos dados, o sistema apresenta a Mensagem "Problemas no envio, tente novamente". (Cena faq - quadro-chave 3) Relata projetos aplicados Cenários Cenário principal. 1) O usuário informa login e senha (Cena relatos quadro-chave 1). 2) O sistema verifica se login e senha conferem. 3) O sistema abre uma cena que possibilita ao usurário cadastrar relatos. O sistema informa quantidade de alunos, turma, projeto de trabalho, escola, descrições e os resultados obtidos com a aplicação do projeto - (Cena relatos - quadro-chave 3). 4) Caso todos os dados sejam preenchidos com sucesso o sistema inclui o projeto e gera a mensagem "dados inseridos com sucesso" (Cena relato quadro-chave 5) Cenário alternativo. 1) Se no passo 2, login e senha não estiverem corretos apresenta a Mensagem "login ou senha incorretos" (Cena relatos quadro-chave 2) 2) Se no passo 3, os dados estiverem preenchidos de foram incorreta, apresenta-se a Mensagem "Dados incorretos ou incompletos" (Cena relatos quadro-chave 4)
Quadro 5: Cenários do sistema Softvali.
77
4.2.2.2. SBLT: Softvali
Apresenta-se na Figura 40 o diagrama proposto para auxiliar na especificação da aplicação a
ser desenvolvida. Sendo que o diagrama Softvali está modelado para ser desenvolvido com um
filme que possui várias cenas. Cada cena deve conter os seus quadros-chave que serão as telas
respectivas a cada seção do website a ser desenvolvido. No centro pode-se observar que existe uma
especificação de cena comum, esta cena não será desenvolvida na aplicação ela apenas foi
representada para facilitar e melhorar a organização da navegação entre as cenas. Ela representa o
que há em comum nas cenas especificadas. Em anexo são apresentadas as tags com as
especificações dos elementos que compõem o diagrama.
78
Entrada
cena 1
Softv ali
contato
Quadro-chav e
equipe
home
quadro-chav e
notícia
Quadro-chav e
relatos
quadro-chav e
Cena comum
relatoscadastro equipe faq contatodownloadhistóricohomehome historico download contatocadastro relatos faqequipe
Univ ali CnpqEscolaCttMar
histórico download
cadastro
faq
Apresentação
Notícias
Relatoslogin
senha
Env iar
quadro-chav e quadro-chav e
quadro-chav e
Histórico do sistemaInstituição/Empresa
Nome
Inserir
Nome
Função
Login senha
senha Env iar
Quadro-chav eQuadro-chav e
Equipe
Perguntas Pergunta
Nome
Env iar
Mensagem
Nome
Env iar
inserir_autorizacao.php
login.php
Notícias_geral.php
resposta_faq.php
listar_relatos.php
MySql
MySql
MySql
MySql
Título das notícias Mais Notícias
noticias_home.php
MySql
Altera
altera_login.php
MySql
login_relato.php
MySql
env ia_email_faq.php
Env iar_email.php
quadro-chav e
«Grafico»lapis
quadro-chav e
«Grafico»logo
quadro-chav e
«Grafico»cidade
Figura 40: Diagrama SBLT das cenas o sistema Softvali.
1.2
1.3
1.6
1.5 1.4
79
download
quadro-chav e 1
Instituição/Empresa
Nome
Inserir
Quadro-chav e 2 Quadro-chav e 3
Dados preenchidos com erro
Voltar
ArquivoData
Voltar
MySql
listar download.php
Autor
Figura 41: Especificação da cena download do sistema Softvali.
cadastro
quadro-chav e 1
Nome
Função
Login senha
senha Env iarAltera
quadro-chav e 5quadro-chav e 4
quadro-chav e 3quadro-chav e 2
usuário já cadastradosenhas não conferem
Voltar Voltar
VoltarVoltar
Campos com omissão de dados Usuário cadastrado com sucesso
Figura 42: Especificação da cena cadastro do sistema Softvali.
80
relatos
quadro-chav e 1
Relatoslogin
senha
Env iar
quadro-chave 4
quadro-chave 2
quadro-chave 5
quadro-chave 3
Quantidade alunos Turma
Projeto de trabalho
Escola
Descrição Resultados
Env iarenv ia_relato.
php
MySql
Dados incorretos ou incompletos Dados carregados com sucesso
Login ou senha incorretos
Voltar Voltar
Voltar
Figura 43: Especificação da cena relatos do sistema Softvali.
81
faq
Quadro-chav e 1
Perguntas Pergunta
Nome
Env iar
Quadro-chav e 3
Quadro-chave 2
Quadro-chave 4
Pergunta
Resposta
Env iarProximaAnterior
Problemas no envio, tente novamente
Pergunta enviada com sucesso
Voltar
Voltar
incluir_resposta.php
nov as_perguntas.php
MySql
Figura 44: Especificação da cena FAQ do sistema Softvali.
contato
Quadro-chav e 2 Quadro-chav e 3Quadro-chav e 1
Mensagem
Nome
Env iar
e-mail enviado com sucesso Houve problemas tente novamente
VoltarVoltar
Figura 45: Especificação da cena contato do sistema Softvali.
82
4.2.2.3. Diagrama E-R: Softvali
Esta seção mostra as tabelas e relacionamentos do sistema softvali.
Figura 46: Diagrama E-R do sistema Softvali.
4.2.3. Implementação
A seguir na Figura 47 apresenta-se o diagrama parcial do sistema web Softvali, este por sua
vez contém uma cena cadastro de usuários para download. A cena é especificada apresentando o
seu conjunto de quadros-chave 2 que se refere a tela de mensagem do sistema, o quadro-chave 3 a
tela dos arquivos que estão disponíveis para download. A seguir nas Figuras 48, 49 e 50 encontra-se
a implementação referente à diagramação apresentada. Sendo que o quadro-chave 3, possui uma
comunicação com a tabela arquivos. Este acesso acontece através de um arquivo PHP para
tratamento dos dados, arquivo este que se encontra listado no Quadro 6.
83
download
Quadro-chav e 2quadro-chav e 1
Instituição/Empresa
Nome
Inserir
Quadro-chav e 3
Dados preenchidos com erro
Voltar
ArquivoData
Voltar
MySql
listar download.php
Autor
Figura 47: Diagramação parcial SBLT do sistema Softvali. Para melhor compreensão da especificação apresentada, esta seção ilustra a cena download do
diagrama Softvali e as telas resultantes após a implementação.
Figura 48: Tela de cadastramento para disponibilizar download.
84
Figura 49: Tela de mensagem do sistema.
Figura 50: Tela disponível para download de arquivos.
$conexao = mysql_connect("inf.univali.br","fabricio","**********"); mysql_select_db("fabricio"); $consulta = mysql_query("SELECT nome, autor, descricao, url, data_autoria FROM arquivo ORDER BY 1"); $n_linhas = mysql_num_rows($consulta); $variaveis = "n=".$n_linhas; //nlinha conta variavel e corre o array ate o numero de linhas existentes for ($i=0; $i < $n_linhas; $i++) { $linha = mysql_fetch_array($consulta);
85
$variaveis.="&nome$i=".$linha['nome']."&autor$i=".$linha['autor']."&descricao$i=".$linha['descricao']."&data_autoria$i=".$linha['data_autoria']."&url$i=".$linha['url']; } echo $variaveis; mysql_close($conexao); ?>
Quadro 6: Arquivo PHP que lista os arquivos disponíveis.
4.3. Engenharia Reversa
Foi realizado um estudo baseado em uma aplicação que já se encontrava em desenvolvimento
para que a validação se torne ainda mais completa.
4.3.1. Descrição
O sistema tem por objetivo principal simular compras em um supermercado, o projeto está
sendo desenvolvido com o intuito de que crianças do ensino médio utilizem o sistema como um
jogo interativo.
A parte do sistema Softvali que foi avaliada para engenharia reversa é um ambiente de
supermercado que visa favorecer a aprendizagem durante a utilização do sistema, conceitos como
matemática também podem possibilitar conhecimentos no campo das ciências naturais, da escrita e
da leitura, passar pelos conhecimentos históricos e geográficos, pela química, física e ainda lidar
com conceitos cotidianos.
4.3.2. Diagrama
Para efeito de comprovar a viabilidade do diagrama e também para realização de engenharia
reversa optou-se por abordar apenas uma parte do software. Vale ressaltar que esta aplicação aborda
vários aspectos pertinentes a um projeto.
86
4.3.2.1. Diagrama de use case: Supermercado
O diagrama de use-case apresentado nesta seção, Figura 51, descreve o cenário do sistema de
supermercado.
Us uá rio
Fa ze r c om pra s
Figura 51: Diagrama de use-case do sistema Supermercado.
Fazer compras Cenários Cenário principal 1) o usuário pega o carrinho para movimentá-lo dentro do supermercado, encolhe uma prateleira que deseja fazer compras. 2) depois da prateleira escolhida aparecem os produtos disponíveis nela, ele escolhe o produto desejado. 3) o produto escolhido aparece com a etiqueta com as especificações do produto, nome, preço, peso, validade, código e imagem do produto.
Quadro 7: Cenário do sistema Supermercado.
4.3.2.2. Diagrama SBLT: Supermercado
Esta seção aborda os diagramas desenvolvidos para especificação do sistema do
supermercado, em Anexo segue as tags com especificações de todos os elementos dispostos no
diagrama.
87
Softv ali
Cena 1
Quadro-chav e 1 Quadro-chav e 2 Quadro-chav e 3
MapCar
Gondola
Voltar
Figura 52: Cena 1 do sistema Supermercado.
A Figura 53 representa um mapa do supermercado, cuja representação está especificada na
Figura 52 como map 1.1, esta especificação mostra como está disponibilizado o supermercado.
1.1
1.3 1.2
88
Quadro-chav e 2
Map
tomate
bebidas2
Açougue
laranja
batata cenora
higiene2
repolho
tempero
alfacemaça
mamão
chuchu
uv a
Congelados
banana
Frios
cebola
bebidas1
Padaria
higiene1Limpeza2limpeza1
Enlatados2BiscoitosCondimentos
Grãos Enlatados1Massas
Caixa 3
Caixa 2
Caixa 1
Caixa 5
Caixa 4
Pacote
GuardaVolumes
cars
Firebird
C++
Figura 53: Especificação do mapa de localização do supermercado.
A Figura 54 apresenta uma das gôndolas do supermercado, a padaria. Para cada uma das
outras gôndolas, deve-se criar uma especificação similar, que obtém o mesmo resultado apresentado
na Figura 55.
1.1.1
89
Quadro chav e
Gondola
dados
docinho
tortabolobolo
bolobolotortabolotorta
pão
pãotorta
bolo
docinho
bolo
Figura 54: Especificação da gôndola da padaria.
Gondola
Quadro-chav e
validade
codigo
dia
peso
preço
nome
Figura
quadro
Figura 55: Especificação da gôndola.
A Figura 56 apresenta a especificação dos carrinhos de compra que circulam dentro do
supermercado, na Figura 53 aparece a notação como 1.1.1. São oito carrinhos que se movimentam
aleatoriamente.
1.3.1
90
Map
Cars
cars 1
cars 3
cars 2
cars 5
cars 8
cars 6
cars 7
cars 4
Figura 56: Especificação dos carrinhos do supermercado.
4.3.2.3. Diagrama E-R: Supermercado
A Figura 57 apresenta as tabelas e relacionamentos que apresentam o sistema diagramado.
Figura 57: Diagrama E-R do sistema supermercado.
91
4.3.3. Implementação
No caso da engenharia reversa os diagramas a implementação é resultado do conjunto dos
diagramas desenvolvidos. A tela a seguir apresenta a interface do sistema.
Figura 58: Interface de desenvolvimento do supermercado.
92
Figura 59: Interface de desenvolvimento da gôndola padaria e a etiqueta de um produto.
IV - CONCLUSÃO E RECOMENDAÇÕES
O diagrama para Sistemas Baseados em Linha de Tempo mostrou-se útil nas fases de
elaboração e concepção de sistemas. Seu uso permite que as equipes de desenvolvimento de
software interajam em cima de protótipos sem a necessidade de implementação destes. Logo, a
economia em termos de tempo mostra-se evidente.
O desenvolvimento do diagrama é um tanto quanto trabalhoso por causa da necessidade de se
detalhar as tags existentes nos estereótipos. A descrição é necessária para que seja possível
apresentar os movimentos ou as ações dos objetos, uma vez que animações não podem ser
encaixadas em diagramas estáticos.
Dentro das ferramentas analisadas, conclue-se que alguns dos estereótipos criados podem ser
representados em outras ferramentas que utilizam SBLT. A diferença é que deve-se fazer uma
analise prévia de como a ferramenta a ser utilizada trabalha com as propriedades dos objetos.
Encontra-se disponível a inserção novas tags para descrever as demais características existentes.
Devido à característica dos elementos ou, da forma de descrição dos estereótipos, tentou-se
criar um diagrama que não ficasse visualmente poluído, uma vez que isso pode acontecer quando se
tem a intenção de trabalhar com vários objetos que se movimentam de formas diferentes. Todas
notações foram criadas visando à apresentação do diagrama se de forma que sua compreensão e
visibilidade.
A notação, bem como as regras de utilização para cada estereótipo, foram descritas e
detalhadas em nível adequado para os atuais usuários de SBLTs. O Rational Unified Process foi
imprescindível para o sucesso no encaixe do foco que o diagrama proposto dá ao desenvolvedor,
uma vez que este percebe as necessidades de se formalizar graficamente a confecção de sistemas,
bem como a de se gerenciar todo o ciclo de desenvolvimento.
94
Estudos de caso são fundamentais para a validação da aplicabilidade do modelo. A aplicação
Softvali fez uso prático de todos recursos de modelagem aqui apresentados. O nível de detalhes com
que se apresentou a transformação do modelo em aplicação comprova o alinhamento coerente entre
os ensaios teóricos - típicos da fase de modelagem, no produto final, apresentado tela a tela no
capítulo 4 da parte de desenvolvimento.
Não se espera entretanto, que esta documentação seja vista como a versão final da
diagramação aqui proposta. É necessário validar mais vezes o modelo para avaliá-lo sob aspectos
particulares que cada ambiente proporciona e corrigi-lo para torná-lo cada vez mais alinhado as
necessidades dos desenvolvedores que o utilizam.
BIBLIOGRAFIA
ALBIR, S. S., UML in a Nutshell: A desktop Quick Reference. Califórnia:
O´Reilly, 1998.
ALMEIDA, A., DAROLT, R., Pesquisa e desenvolvimento em UML.
<http://www.uml.com.br/arquivos/tutoriais/UNISUL.pdf>. Acesso em 19/04/2003.
ANDRÉ, C., JALES, J., Técnicas de programação - UML- Tipos de diagramas.
<http://www.jorgejales.hpg.ig.com.br/index.htm>. Acesso em 26/04/2003.
BOOCH, G., RUMBAUCH, J., JACOBSON I., UML Guia do Usuário. Rio de Janeiro:
Campus,2000.
BEHZADI, S. Apresentações com Flash Mx. Artigo do Infosquad.net. Disponível em:
<http://www.infosquad.net/materias/index.php?ID=30 > Acesso em: 15/02/2002.
BILL, P. Introdução ao Macromedia Flash para PocketPC. Artigo do Devnet. Disponível em:
<http://www.macromedia.com/br/devnet/mx/articles/f5_ppc/> Acesso em: 15/02/2002.
CHAMBERS, M. Uma visão geral da interação cliente/servidor, usando o Macromedia Flash e
banco de dados. Artigo sobre o Macromedia Flash. Disponível em:
<http://www.macromedia.com/br/devnet/mx/articles/flash_databases/> Acesso em: 15/02/2002.
CUNHA, P.R. Engenharia de Software, Departamento de Eng. De software, FCTUC.
<http://www-ctp.di.fct.unl.pt/~amm/ASII/UML-RUP(6)-2.pdf>. Acesso em 04/05/2003.
DROBLAS, A., GREENBERG, S., Adobe Premiere 6 Bible. New York: Hungry Minds,2001.
DURAN, R. Processo de desenvolvimento Interativo e Incremental. Material do curso de
Implantação de Processo e Arquitetura . Realizado pela B4U internet e eventos 2003.
96
FARIA, J. P. UML – Diagramas de Classes. <http://www.fe.up.pt/~jpf/teach/POO/RUP.pdf>.
Acesso em 04/05/2003.
FLEISCHHAUER, Luciana Irene Amaral. Concepção de um Modelo Computacional Baseado
em Projetos de Trabalho Para Suporte À Educação. Tese de doutorado do Programa de Pós-
Graduação em Engenharia da Produção. Universidade Federal de Santa Catarina. Jul, 2002.
FOWLER, M., SCOTT, K., UML Essencial – Um breve guia para a linguagem-padrão de
modelagem de objetos. Porto Alegre: Bookman, 2000.
FRANCO, G.J.R.G., SANTOS, W., Diagramas de implementação.
<http://www.dcc.ufmg.br/~gorgulho/tbd/>. Acesso em 19/04/2003.
FURLAN, J. D., Modelagem de objetos através da UML – Análise de desenho orientado a
objeto. São Paulo : Makbon Books, 1998.
GALVEZ, J., Técnica para facilitar o acesso de documentos XML e Flash. <
http://www.pontoflash.com.br/dicas/ >. Acesso em 15/02/2002.
JONES, M., Fundamentos do Desenho Orientado a Objeto com UML. São Paulo: Makbon
Books, 2001.
LARMAN, C., Utilizando UML e Padrões – Uma introdução a analise e ao projeto orientados
a objeto. Porto Alegre:Bookman,2000.
MAGALI, F. Pedagogia de Projetos. Disponível em
[http://cdisp.org.br/pedagógico/projeto/carac.htm]. Acesso em 12/06/2003.
MELO, A.C., Buscando Novos caminhos por meio da UML
<http://www.anacristinamelo.eti.br/artigos/Artigo_Buscando_Novos_Caminhos.pdf>. Acesso em
19/04/2003.
97
MENDES, M. A. Squadra Development Tools Securyt Solutions Training Center Consulting.
<http://www.assespro-mg.org.br/docs/3ocafe.pdf>. Acesso em 04/05/2003.
MULLER, O., Ferramenta de Autoria para Criação de Sites e Armazenagem de Materiais de
Didáticos em Bibliotecas Digitais Via Internet. 2001. Relatório de Estágio (Graduação em
Ciência da Computação) - Centro de Ciências Tecnológicas da Terra e do Mar - CTTMar,
Universidade do Vale do Itajaí - UNIVALI, Itajaí.
MURDOCK, K.L., 3ds max Bible. New York: Hungry Minds,2001.
NIED, Pedagogia de Projetos. Disponível em [http://cdisp.org.br/pedagógico/ projeto/carac.htm].
Acesso em 12/06/2003.
OLIVEIRA et al., UML – Conceitos fundamentais.
<http://www2.fundao.pro.br/articles.asp?cod=1>. Acesso em 16/04/2003.
OMG – Object Management Group : Introduction to OMG's - Unified Modeling Language™
(UML™). <http://www.omg.org/gettingstarted/what_is_uml.htm>. Acesso em 26/04/2003.
PAGE-JONES, M., Fundamentos do Desenho Orientado a Objeto com UML. São Paulo:
Makron Books, 2001.
PAULA, W.P., Engenharia de software – Fundamentos, métodos e padrões. Rio de Janeiro:
LTC Editora, 2001.
PEDRYCZ, W. & PETERS, J. F. Engenharia de Software – Teoria e Prática. Rio de Janeiro
:Editora Campus, 2001.
PINTO, J.M.Sites Dinâmicos com Flash 5 & PHP 4 e Banco de Dados MySQL. São Paulo:
Érica, 2001.
POMPERMAIER, L. Visão Geral do RUP e da UML.
<http://www.inf.pucrs.br/~pomper/esi/aulas/aula02.pdf >. Acesso em 04/05/2003.
98
RATIONAL. Rational Unified Process: Product Information.
<http://www.rational.com/products/rup/prodinfo.jsp?SMSESSION=NO> Acesso em 04/05/2003.
REINHARDT, R., LENTZ, J.W., Flash 5 Bible. New York: Hungry Minds,2001.
Revista CadDesing
REY, C., Macromedia Flash MX – Guia Autorizado de Treinamento Macromedia. Rio de
Janeiro: Alta Books, 2002.
SALM, J. F. J., Extensões da UML para Descrever Processo de Negócio. Tese de Mestrado do
Programa de Pós-Graduação em Engenharia da Produção. Universidade Federal de Santa Catarina.
Janeiro, 2003.
SAMPAIO, M. C., UML. <http://www.dsc.ufpb.br/~eloi/docencia/uml/uml.htm> Acesso em
26/04/2003.
SILVA, D.M., UML Guia de Consulta Rápida. São Paulo: Novatec, 2001.
SOMERVILLE, I., Engenharia de Software. Tradução de: André Mauricio de Andrade Ribeiro;
São Paulo: Addison Wesley, 2003.
TAKAISHI, M., CADDESING – Construa um sistema solar utilizando o 3D Studio Max. Ano
4 N.o 35. Rio de Janeiro: Grand ABC Editora Gráfica, 1998.
TURQUETTI, R.F., CADDESING – Utilize o keyframe para animação em seqüência. Ano 3
N.o 26. Rio de Janeiro: Grand ABC Editora Gráfica, 1998.
TRIOLO, H. Macromedia Mx e PHP.Artigo sobre o Macromedia Flash. Disponível em:
<http://www.macromedia.com/br/devnet/mx/flash/articles/flashmx_php.html> Acesso em:
15/02/2002.
99
WOLFF, L. , UML : Unified Modeling Language. Abrange sua história, definições, arquivos e
sites relacionados. Disponível em : <http://www.eps.ufsc.br/~wolff>. Acesso em 26/04/2003.
ANEXO