Oohdm
O Método OOHDM O método OOHDM é um dos métodos de modelagem de aplicações hipermídia mais utilizados atualmente. Embora seja trabalhoso e penoso de ser realizado oresultado final é o que compensa. Um site modelado pelo OOHDM possui uma estrutura sólida e robusta, sem falar da documentação. Todo diagrama produzido em cada uma das fases do modelo OOHDM é uma excelente fonte de documentação. O OOHDM é apontado como um dos mais promissores métodos que já surgiram para este fim.
OOHDM considera o processo de desenvolvimento da aplicação hiperm[dia como um desempenhadas em incrementais de des onstruído ou enriq – Projeto Conceitual ( OF7 Swip view nent page idades, terativos e tapa um modelo é – Projeto de Navegação – Projeto da Interface Abstrata – Implementação A modelagem conceitual é a etapa que se destina a análise do domínio da aplicação. Constrói-se um Esquema de Classes Conceituais que represente os objetos e relacionamentos existentes no domínio da aplicação.
Nesta etapa preocupa-se com a estrutura conceitual da informação, deixando de lado a aparência e as formas de uso. A construção de um esquema conceitual bem elaborado poderá implicar em seu reuso, quando entro do mesmo domínio Pode-se mensurar o ganho das aplicações hipermídia na noção de navegação, sendo a aplicação uma visão navegacional do navegacional é definido o universo de objetos navegacionals , seus acessos e suas transformações.
Já no projeto de interface, especifica-se que objetos de interface serão vistos pelo usuário e, particularmente, a forma que tomarão diferentes objetos navegacionais. Vantagens inerentes à Utilização do Modelo OOHDM – Desenvolvimento de aplicações com base em objetos, tornando-os mais robustos e de fácil modificação. São utilizadas premissas de modelagem (objetos, classes), simplificando a transição de uma atividade para outra. – Há poderosos formalismos, já existentes para especificar a estrutura, o comportamento e as relações dos objetos e podemos adaptá-los ao campo da hiperm[dia. Reutilização de componentes existentes, quando descritos como objetos, é altamente viável em novas aplicações Levantamento de Requisitos A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deverealizar, ua Interface com os demais elementos e sob quais restrições o sistema deveoperar. os requisitos dos sistemas devem estabelecer o que o sistema deve fazer ao invés de como isto será feito. especificação um documento de requisitos de software é montando.
Modelagem Conceitual A modelagem conceitual ou de domínio destina-se ? compreensão do domínio problema e à construção de modelos adequados deste domínio, enquanto o projeto lida com abstrações no universo do software e tende a maximização da modularidade e do reus projeto lida com abstrações no universo do software e tende maximização da modularidade e do reuso. O modelo do projeto é independente da implementação no sentido em que, embora possa levar em consideração algumas configurações de implementação, não é condicionado por um ambiente de implementação em particular.
Ela tem por objetivo a construção de um esquema contendo classes, objetos, relacionamentos e subsistemas existentes para o dominio especificado. A descrição de classes segue a notação da orientação a objetos, mas seus atributos podem ser multi- tipados, representando assim diferentes perspectivas da mesma entidade real. E Agregação e Generalização/Especializaçào são utilizadas para aumentar o poder de abstração do sistema.
Este esquema consiste de um conjunto de objetos e classes unidos entre si por relacionamentos; como os objetos são instâncias de classes, um relacionamento entre as classes faz com que o relacionamento entre os objetos seja abstraido. Obtêm-se, dessa maneira, três mecanismos de abstração: Agregação, Generalização/Especialização e um conceito de empacotamento, os subsistemas. A Agregação é útil na descrição de Classes complexas como agregadas de classes mais simples. A Generalização/Especialização é utilizado na construção de Hierarquias de Classes e no uso de herança como um mecanismo de compartilhamento.
Os subsistemas são um mecanismo de empacotamento para a abstração de modelos de domínio complexos. O diagrama resultante da modelagem conceitual, segunda etapa do OOHDM, é designado de Esquema Concei 3 diagrama resultante da modelagem conceitual, segunda etapa do OOHDM, é designado de Esquema Conceitual. No esquema conceitual estão representadas todas as classes e relacionamentos do domínio da aplicação, bem como também odos os mecanismos de refinamento descritos nesta etapa da modelagem Modelagem de Navegação Consiste na projeção de aplicativos hipermídia realizar navegação através de um espaço de informação.
Dessa forma, o projeto da estrutura de navegação é uma etapa crucial no empreendimento do desenvolvimento. É proposto pelo OOHDM a construção de um modelo navegacional compartilhado focado nos objetos e relacionamentos do domínio No Projeto Navegacional, são estabelecidas as estratégias de navegação e as visões que um determinado usuário terá ao navegar pela aplicação. O projeto da estrutura de navegação de um aplicativo de hipermídia considera: – Os objetos a serem navegados e seus atributos.
Além disso, constitui a relação entre os objetos e suas definições constantes no esquema conceitual como visões orientadas a objetos das classes e relacionamentos conceituais – As estrutura subjacente de navegação e os contextos navegacionais com vistas à organização do espaço de navegaçao. – Aparências dos objetos de acordo com o contexto em que são visitados e especificar tais diferenças claramente. As estruturas de elo existentes entre os objetos que serão avegados – As ações de navegação fora do fluxo definido e seus efeitos na navegação nos objetos de origem e alvo e em outros objetos relacionado 4 seus efeitos na navegação nos objetos de origem e alvo e em outros objetos relacionados A base de noção de navegação é o “nó”, que neste caso, são as classes navegacionais que derivam das classes conceituais através do mapeamento dos atributos existentes.
No caso de novos atributos, como, por exemplo, âncoras, apesar de não ser comum, uma classe navegacional pode conter atributos de mais de uma classe conceitual. Um nó pode ser classificado como atômico ou composto e é descritos em atributos e âncoras para elos no caso de serem atômicos, e como um conjunto de nós componentes no caso de serem compostos. Os Contextos Navegacionais definem um conjunto de classes “decoradoras” que adaptam cada nó no contexto para as estruturas âncoras-atributos necessárias ao contexto. A ligação dos objetos navegacionais e podem ser de um-a-um ou um-a-muitos.
O resultado da travessia de um elo é expresso pela definição das semânticas navegacionais, como resultado do comportamento do elo. Projeto da Interface Abstrata A modelagem de uma interface abstrata é construída definindo objetos perceptíveis em termos de interface. Estas classes são definidas como agregações de elementos primitivos, como caixas de textos, botões, imagens, e também de maneira recursiva, utilizando outras classes de interface. O mapeamento dos Objetos de Interface ocorre a partir dos objetos navegacionais, provendo assim uma aparência perceptivel do sistema.
O comportamento da interface é declarado especificando como eventos externos ou gerados pelo usuário são tratados, S da interface é declarado especificando como eventos externos u gerados pelo usuário são tratados, e em como se dá a comunicação entre a interface e os objetos navegacionais. A especificação do modelo abstrato de interface defini metáforas de interface e descreve suas propriedades estáticas e dinâmicas, seus relacionamentos com o modelo navegacional de uma forma independente de implementação.
Necessidades de especificação – Aparência interfacial de cada objeto navegacional e suas âncoras – Demais objetos de interface afim de diversificar funções da aplicação, e suas aplicabilidades – os relacionamentos entre os objetos de interface e avegacionais, tais como o modo com que um evento externo, afetará a navegação. – Comportamento de interface em caso de navegação ou de eventos externos no comportamento de diferentes objetos de interface.
Modelo de Projeto ADV O modelo de projeto ADV foi criado para especificar clara e formalmente a separação entre a Interface do usuário e os componentes de um sistema de software, e para oferecer um método de projeto independente de implementação. Para expressar padrões de comunicação entre objetos, em termos de sen,’iços oferecidos e requeridos, utilizam- e os Diagramas de Configuração. No contexto de OOHDM, concentramos nosso interesse na interação do usuáriopcom o aplicação hiperm[dia e, especialmente, nos objetos de interface.
A fim de permitir a expressão da associação entre eventos externos e ADVs, Os ADVcharts suportam o alinhamento de estados e ADVs. Além disso são a expr estados e ADVs. Além disso são a expressão interfacial dos diagramas de navegação e são compostos por estados, atributos e transições. Implicações para a definição do modelo de interface de uma aplicação hipermídia com OOHDM Definição da estrutura geral da interface da aplicação – Definição dos ADVs para os nós, índices, etc. Mapeamento de relacionamentos estáticos entre os componentes de um ADV. – Especificação do ADVchart mostrando a dinâmica da aplicação hiperm[dia. Implementação É a última etapa do processo de construção de aplicativos hipermídia_ O sistema hipermídia a ser executado é produzido após o mapeamento do design abstrato da interface (os objetos perceptíveis e suas transformações) em objetos de interface concretos (escolhidos no ambiente de Implementação). ?? necessário a definição dos objetos de interface de acordo com a especificação da interface abstrata, implementar transformações da forma como foram definidas nos ADVcharts e fornecer suporte para a navegação através da rede hipermídia. há muitas implementações possíveis, mas nenhuma delas destaca- se por alcançar tanto maior desempenho como maior flexibilidade e facilidade de manutenção. Além disso, igualmente importante realizar o processo de documentação de todas as etapas, a documentação na fase de implementação é muito importante afim de que problemas sejam facilmente Resolvidos