• Nenhum resultado encontrado

proposta de diagrama voltado a sistemas com abordagem

N/A
N/A
Protected

Academic year: 2023

Share "proposta de diagrama voltado a sistemas com abordagem"

Copied!
116
0
0

Texto

O objetivo deste trabalho é estender a UML para atender necessidades de modelagem ainda não conhecidas para sistemas baseados em linha do tempo, utilizando o software Macromedia Flash como ferramenta de referência. Portanto, a proposta consiste em desenvolver um diagrama para auxiliar no processo de desenvolvimento e documentação de projetos para sistemas baseados em time-shift.

APRESENTAÇÃO

JUSTIFICATIVA

IMPORTÂNCIA

OBJETIVOS DO TRABALHO

Objetivo Geral

Objetivos Específicos

METODOLOGIA

Definir o processo de desenvolvimento, ou seja, o caminho mais coerente a ser seguido pelo desenvolvedor do sistema.

FERRAMENTAS BASEADAS EM LINHA DE TEMPO

  • Discreet 3ds max
  • Macromedia Flash
  • Adobe Premiere
  • Análise Comparativa dos SBLT´s

Vale acrescentar que o 3ds max é utilizado para objetos criados em AutoCad, o que permite um maior grau de precisão na edição de objetos. A Figura 2 ilustra o conceito de linha do tempo, no 3ds max chamada Track View, representada por keyframes (camada de organização da cena).

Figura 1: Pontos de visão do 3ds Max 4.
Figura 1: Pontos de visão do 3ds Max 4.

MACROMEDIA FLASH

Estrutura da Interface Macromedia Flash

A janela da linha do tempo exibe cada quadro de um filme; cada camada aparece na linha do tempo como um sublinhado separado. Na Figura 9a você pode ver o filme como a parte principal do arquivo e dentro dele o layout da cena e a linha do tempo.

Figura 8: Apresentação da linha de tempo e da disponibilização de seus componentes.
Figura 8: Apresentação da linha de tempo e da disponibilização de seus componentes.

Interação do Flash com Fontes Externas

  • Flash e XML
  • Flash e PHP
  • Flash e ASP

Um exemplo de integração Flash e XML é um sistema de corretagem de valores mobiliários que armazena todas as suas informações, como nomes de usuário, senhas, IDs de sessão, títulos de carteira e informações de transações em um banco de dados. O script do servidor que transfere informações entre o Flash e o banco de dados lê e grava dados no formato XML.

Figura 10: O fluxo e a conversão de dados entre um filme do Flash.
Figura 10: O fluxo e a conversão de dados entre um filme do Flash.

UML – LINGUAGEM UNIFICADA DE MODELAGEM

  • História da UML
  • Importância da Especificação de Sistemas
  • Estrutura da UML
    • Diagrama de Caso de Uso
    • Diagrama de Classes
    • Diagrama de Objetos
    • Diagrama de Gráfico de Estados
    • Diagrama de Atividades
    • Diagrama de Seqüência
    • Diagrama de Colaboração
    • Diagrama de Componentes
    • Diagrama de Implantação
  • Mecanismo de extensão da UML
    • Estereótipos
    • Valores Atribuídos
    • Restrições

A notação que a UML usa para um diagrama de casos de uso é apresentada na Figura 12. Um diagrama de classes indica a estrutura estática de um sistema e as classes representam as manipulações que podem ser executadas no sistema. O que distingue um diagrama de objetos de um diagrama de classes é o seu conteúdo específico (SILVA, 2001), ou seja, um diagrama de objetos mostra múltiplas instâncias de uma classe e não a classe propriamente dita (FURLAN, 1998).

O diagrama em questão é uma variante do diagrama de estado em que a maioria, senão todos, os estados são estados de atividade. Os diagramas de sequência e colaboração são chamados de diagramas de interação e são usados ​​para modelar os aspectos dinâmicos dos sistemas. Um diagrama de sequência é um diagrama de interação que enfatiza a ordenação temporal das mensagens (BOOCH et al. 2000).

Como num diagrama de sequência, as setas indicam as mensagens enviadas num caso de uso. Um diagrama de componentes mostra os vários componentes de um sistema e suas dependências; geralmente, o componente representa um módulo de código físico.

Figura 11: Origem e evolução da UML.
Figura 11: Origem e evolução da UML.

PROCESSO DE DESENVOLVIMENTO

Processos de Software

  • RUP – Rational Unifed Process
    • Fase
    • Concepção
    • Elaboração
    • Construção
    • Transição
    • Iterações
    • Workflow

Em termos de governança, o RUP fornece um processo disciplinado para tarefas e responsabilidades em um sistema em desenvolvimento (BOOCH et al. 2000). O gerenciamento de riscos também ocorre no RUP, de forma que os riscos para o sucesso do projeto sejam identificados e atacados logo no início, para que haja tempo suficiente para uma reação adequada (BOOCH et al. 2000). Ao final da fase de planejamento, os objetivos do projeto são examinados para se tomar uma decisão sobre a viabilidade de continuidade do projeto (BOOCH et al. 2000).

Esses riscos geralmente ocorrem porque os casos mais difíceis ficam para o final do projeto. Na fase de transição, os responsáveis ​​pelo desenvolvimento do projeto ficam à disposição do usuário, pois sempre há problemas que precisam ser resolvidos, ajustados ou eliminados, que podem ser identificados na utilização do sistema. Esta fase inicia-se com uma versão beta do sistema e logo é substituída por uma nova versão (BOOCH et al. 2000).

Cada iteração passa por diferentes fluxos de trabalho do processo, embora com ênfase diferente em cada um deles (BOOCH et al. 2000). Gerenciamento de configuração: controla as alterações do sistema enquanto mantém a integridade dos artefatos do projeto.

Figura 22: O ciclo de vida de desenvolvimento de um software no RUP.
Figura 22: O ciclo de vida de desenvolvimento de um software no RUP.

NOTAÇÃO DO DIAGRAMA PROPOSTO

  • Estereótipos
    • Tag’s
    • Constraint
  • Notação
  • Regras para construção
  • Visão Geral do Diagrama Proposto
    • Especificação da Cena

As notações do diagrama são descritas ao longo deste capítulo, mostrando como cada representação deve ocorrer e as técnicas necessárias para sua construção. Além disso, é discutida a integração do diagrama em uma ferramenta CASE para demonstrar a funcionalidade e aplicabilidade do diagrama, para que sua viabilidade possa ser melhor demonstrada. Estudos de caso foram desenvolvidos para demonstrar a relação entre o diagrama proposto e a UML, bem como para ilustrar a utilização do diagrama em diferentes tipos de aplicações.

Um tipo base será utilizado para especificar o metamodelo a ser representado juntamente com a anotação do diagrama (SILVA, 2001). Descrição: O símbolo indica que o elemento possui repetição, ou seja, pode aparecer diversas vezes durante a montagem do diagrama. Possuem especificações que serão identificadas pelos níveis que serão representados durante a construção do diagrama.

Descrição da associação: Representa a comunicação entre cenas, entre entidades externas (como bancos de dados ou outros filmes) ou entre objetos no diagrama e também pode representar entrada e/ou saída de dados. Esta seção discute as regras de relacionamento do diagrama proposto, mostrando brevemente como os estereótipos criados podem ser organizados dentro do diagrama.

Figura 23: Relacionamento entre os elementos do diagrama.
Figura 23: Relacionamento entre os elementos do diagrama.

CONFIGURAÇÃO DE FERRAMENTA CASE

Essa ferramenta também é utilizada para gerenciamento de projetos, que permite descrever os ciclos de desenvolvimento de um projeto, além de fornecer informações para acompanhamento de recursos desde a concepção inicial até os diferentes aspectos do ciclo de vida desses projetos, como testes, manutenção e controle de versões (TUTORIAL ENTERPRISE ARCHITECT, 2003). A ferramenta Enterprise Architect permite adicionar novos estereótipos através de um esquema aberto, em formato XML (Extensible Meta-Language). Os estereótipos apresentados neste trabalho são descritos em um arquivo XML no esquema do Enterprise Architect, com o mesmo conteúdo mostrado na notação do diagrama, conforme mostrado na Tabela 2.

Uma vez definidos os estereótipos no arquivo XML, eles devem ser incorporados ao Enterprise Architect. Portanto, é importante que os meta arquivos (imagens em formato EMF) estejam no mesmo diretório do arquivo a ser importado e que haja um projeto em andamento. O processo de importação é realizado através da aba Resource View do componente Workspace (Figura 26), é necessário clicar com o botão direito nos perfis UML, selecionar a opção Import Profile (Figura 27) e apontar a caixa de diálogo de abertura do arquivo para o documento XML.

Após a conclusão bem-sucedida do processo de importação, os elementos ficam disponíveis na linha do perfil UML na visualização de recursos e, para acessá-los, é necessário clicar no elemento desejado e arrastá-lo para onde deseja criar o diagrama. Os rótulos dos elementos aparecem na barra de propriedades quando selecionados, conforme mostrado na Figura 28.

Figura 28: Exemplo dos estereótipos já importados na ferramenta.
Figura 28: Exemplo dos estereótipos já importados na ferramenta.

INTEGRAÇÃO DIAGRAMA PROPOSTO COM PROCESSO DE

Para facilitar a compreensão do design do sistema, sugere-se também que as cenas se refiram aos casos de uso, ou seja, na descrição dos cenários de cada caso de uso, faça referência à cena associada, conforme mostrado na Figura 31. Se no passo 2, o nome do projeto estiver cadastrado, aparecerá a mensagem "Nome do projeto já cadastrado".

ESTUDO DE CASO

Aplicação projeto de trabalho

  • Descrição
  • Diagramas
    • Use-Case: Projeto de trabalho
    • SBLT: Projeto de trabalho
    • Diagrama E-R: Projeto de trabalho
  • Implementação

O Projeto de Obra visa reestruturar e transformar o espaço escolar num espaço de interações muito próximo do mundo real e das suas múltiplas dimensões. Um Projeto de Trabalho é uma atividade proposital, focada em um objetivo que dá sentido às diferentes atividades que serão desenvolvidas pelo grupo. Não existe um tempo definido para o desenvolvimento de um projeto de trabalho; o planeamento do projeto de trabalho deverá ser flexível para que o tempo e as condições do seu desenvolvimento sejam sempre reavaliados em função dos objetivos inicialmente propostos;

Cada projeto de trabalho envolve as experiências e expectativas do grupo, portanto o seu trabalho não deve ser comparado com outros. O projeto de trabalho deve ser desenvolvido com base na realidade de cada grupo, não existe uma realidade única ou uma verdade única. Cada grupo tem seu tempo para desenvolver seu projeto de trabalho, os participantes possuem ritmos e estilos diferentes;

Todos podem aprender, inclusive o educador, o que torna a experiência de cada um fundamental na formulação do problema e no desenvolvimento do Projeto de Trabalho. O sistema também deverá apresentar detalhes de projetos aplicados a determinadas turmas e detalhes de projetos de trabalho agrupados por professores.

Figura 32: Diagrama de use-case do sistema projeto de trabalho.
Figura 32: Diagrama de use-case do sistema projeto de trabalho.

Projeto Web

  • Descrição
  • Diagrama
    • Use-case: Softvali
    • SBLT: Softvali
    • Diagrama E-R: Softvali
  • Implementação

Os usuários têm a opção de cadastrar login e senha para acessar campos que permitem reportar solicitações de projetos de trabalho, descrevendo os resultados dessas aplicações. Se no passo 2 o usuário tiver preenchido incorretamente algum dos campos ou deixado dados, a Mensagem será exibida. O sistema envia os dados para o e-mail do administrador e em seguida exibe a Mensagem “E-mail Enviado com Sucesso” (quadro-chave de contato da cena 2).

Se houver problemas no envio da mensagem no passo 2, a mensagem “Ocorreram problemas no envio” será exibida. A Figura 47 abaixo mostra o diagrama parcial do sistema web Softvali, que por sua vez contém uma cena de cadastro de usuário para download. A cena é especificada mostrando seu conjunto de quadros-chave 2 que se referem à exibição de mensagens do sistema, quadro-chave 3 à exibição de arquivos que estão disponíveis para download.

Figura 39: Diagrama de use-case do sistema Softvali.
Figura 39: Diagrama de use-case do sistema Softvali.

Engenharia Reversa

  • Descrição
  • Diagrama
    • Diagrama de use case: Supermercado
    • Diagrama SBLT: Supermercado
    • Diagrama E-R: Supermercado
  • Implementação

Esta seção discute os diagramas desenvolvidos para especificar o sistema de supermercados. O apêndice contém tags com especificações de todos os elementos dispostos no diagrama. A Figura 53 mostra um mapa do supermercado, cuja visualização na Figura 52 é especificada como mapa 1.1. Esta especificação mostra como o supermercado pode ser alcançado. Uma especificação semelhante deve ser criada para cada uma das outras nacelas, o que produzirá o mesmo resultado mostrado na Figura 55.

A Figura 56 apresenta a especificação dos carrinhos de compras que circulam dentro do supermercado, na Figura 53 a notação aparece como 1.1.1. Sua utilização permite que equipes de desenvolvimento de software interajam a partir de protótipos sem a necessidade de implementá-los. O desenvolvimento do diagrama é um tanto trabalhoso devido à necessidade de delinear os rótulos contidos nos estereótipos.

O Processo Racional Unificado foi essencial para o sucesso da adaptação do foco que o diagrama proposto dá ao desenvolvedor, pois entende a necessidade de formalizar graficamente a criação de sistemas, bem como gerenciar todo o ciclo de desenvolvimento. O nível de detalhamento com que a transformação do modelo foi apresentada na aplicação comprova a aproximação coerente entre os testes teóricos – típicos da etapa de modelagem, no produto final, apresentado tela por tela no capítulo 4 da parte de desenvolvimento.

Figura 51: Diagrama de use-case do sistema Supermercado.
Figura 51: Diagrama de use-case do sistema Supermercado.

Imagem

Figura 3: Curvas de funções que direcionam os movimentos do objeto.
Figura 6: Ambiente de trabalho para edição de trilhas de vídeos.
Figura 8: Apresentação da linha de tempo e da disponibilização de seus componentes.
Figura 9: a) Estrutura da interface do Flash
+7

Referências

Documentos relacionados

Projetos como jardim vertical ou horizontal, horta orgânica, reciclagem de papel e outros resíduos sólidos, compostagem de restos de alimentos produzidos na escola, técnicas