| Autor |
Mensagem |
|
|
Matheus,
Sim! As classes do QT utilizam a API do sistema operacional que já possui widgets, ao menos no windows. Você pode perfeitamente criar os seus widgets, porém para colocá-los na tela, você precisa interagir com a API do sistema operacional. Então, mesmo em casos como o Firefox, que renderiza a página desenhando os componentes e tal, ele tem um widget que é o componente onde a página é mostrada, que é registrada no Windows.
E isso é bom, afinal, você centraliza o código de desenho de janelas e componentes em um só lugar e permite o gerenciamento de tal para todos os aplicativos de uma só forma. Exemplo: se todos os programas usarem a API do SO para desenhar os componentes, é possível que se aplique temas que afetam todos os programas ao mesmo tempo.
Agora falando de C++: na espec da linguagem não existe uma api para criação de interfaces gráficas (GUI). Porém existem as famosas e mais utilizadas, que atualmente são o QT e o GTK+ (ambas multiplataforma). Antigamente se usava também o MFC e o da Borland (não lembro o nome), para Windows. Que eu saiba, o QT no Windows utiliza a API do SO para criar os componentes, exceto aqueles que não existem no SO, para aproveitar a parte de temas, etc. No Linux (KDE), como o QT é a base para todos os aplicativos, este renderiza os componentes, sendo que inclusive é mais integrado ao SO. É possível ver isso ao instalar o Firefox (GTK+) no KDE e tentar salvar um arquivo. Você verá que o diálogo que for aberto não terá o tema dos outros aplicativos, nem o diretório padrão e os atalhos. Isso porque no KDE é o QT que trata isso. O mesmo ocorre no Gnome com o GTK+.
Tipo, temos o framework QT, que além de MVC e outras coisas ele também tem a parte gráfica. Mas isso são somente chamadas ao sistema de janelas?
Não são simples chamadas ao sistema, pois ele expõe a parte de signals e slots, que é uma forma de IPC bem bacana. Além disso, existem diversos widgets que o SO não possui, e esses são desenhados pelo QT (e registrados no Windows, no caso, como Janelas).
Agora... por que vc perguntou isso? Apenas curiosidade? :]
[[]]'s
|
 |
|
|
Opa, estarei lá tanto hoje na palestra da Samsung quanto amanhã na EXPOCOM.
Recomendo os eventos, pessoal. Qualquer coisa me mandem um e-mail.
[[]]'s
|
|
|
|
Tenho uma idéia, mas não sei se é uma boa.
Seria usar o HDFS do projeto Hadoop da Apache para armazenar as imagens em SequenceFiles, e caso fique lenta a busca via MapReduce, usar Memcached para ter as imagens mais acessadas em cache ou algo parecido. O bacana é que fica tudo distribuído, com alta escalabilidade e disponibilidade. Mas a complexidade aumenta.
Pesquise sobre o MongoDB tbm. Ele é feito para consultas online, então talvez seja mais adequado.
[[]]'s
|
|
|
|
Pessoal da Caelum, vocês tem alguma notícia sobre o livro?
Já sabem qual vai ser o valor do mesmo? Tenho interesse em adquirí-lo assim que sair.
E o evento? Vai rolar?
[[]]'s
|
|
|
|
cake,
Procure ler os livros citados. É a melhor forma de aprender.
Vou tentar passar algum conceito e depois fazer alguns comentários para tentar enriquecer um pouco a thread.
O diagrama de casos de uso identifica os requisitos funcionais de usuário do seu sistema, ou seja, te ajuda a entender e enxergar as funcionalidades que o sistema deve prover a um ou mais tipos de usuários (atores). Ele é um diagrama que faz parte da visão comportamental do sistema, enquanto o diagrama de classes faz parte da visão estrutural. Enfim, ele também serve para auxiliar no levantamento de requisitos do seu sistema, que é essencial para a definição do escopo do projeto, e deve ser feito antes de se pensar em arquitetura (salvo alguns casos, como por exemplo restrição de uso de tecnologia, etc).
Após ter os requisitos e o escopo definido, vc começa a atacar o problema de como modelar o seu sistema para resolver os problemas definidos. Aí entra arquitetura de software, design, conhecimento de POO (se for essa a sua abordagem), etc.
Em minha opinião, se você está com dificuldade em montar o diagrama de classes é porque você ainda não entendeu ou definiu todo o problema, ou então porque ainda falta conhecimentos de programação (exemplo: POO).
E criar o diagrama de casos de uso a partir do de classes soa muito estranho para mim. Na verdade, não sei se é possível fazer isso sem conversar com o cliente ou observar o sistema em funcionamento. (fica aí um gancho para discussão, pessoal).
[[]]'s
|
|
|
|
Wellington, obrigado pela ajuda!
Pesquisando um pouquinho, descobri que a tática de ter uma interface "Component" com "install()" em que as implementações saberiam como usar e tal faz parte do design pattern Strategy (http://en.wikipedia.org/wiki/Strategy_pattern).
Também achei uma alternativa para evitar a repetição de código em comum dos processos de instalação de componentes. É o design pattern Template Method (http://en.wikipedia.org/wiki/Template_method_pattern), que sugere a construção de uma classe abstrata que possui métodos referentes a fases do processo (no caso de instalação). Então, as classes que herdam desta, devem implementar os métodos abstratos ou sobrescrevê-los quando o comportamento for específico.
Wellington, acredito que neste caso o Template Method é uma solução mais adequada do que o GenericProcess, pq evita que alguém implemente Component, por exemplo, e não use o GenericProcess, refazendo código.
Agora em relação a separar a entidade Component da classe que instala um componente, estou pensando no seguinte: vou definir a interface Component em que suas implementações (ex: COMPlusComponent) tem os dados específicos de cada tipo (ex: instalar como proxy?). E vou criar uma outra estrutura de classes usando o Template Method, em que a classe abstrata seria ComponentInstaler (e uma subclasse seria ComPlusComponentInstaller). Aí resta um detalhe: precisaria de uma classe que devolve um instaler a partir de um componente (conforme o tipo). O que eu pensei foi que dessa forma, apesar de duplicar o número de classes (rs), eu não terei repetição de código, aumentarei a coesão (Component não serviria para 2 coisas ao mesmo tempo) e diminuirei o acoplamento (uma classe intermediária vai ligar Component a ComponentInstaller), de acordo com o GRASP. Só fico pensando ainda se existe algum pattern para essa ligação Component com ComponentInstaller.
E aí, pessoal? O que vocês acham disso tudo?
Obrigado.
|
|
|
|
Pessoal,
Estou com um problema complicado para modelar e não estou achando uma boa solução. Vocês podem, por favor, dar uma olhada para mim? Acho legal para o fórum porque é um caso que pode gerar discussões interessantes.
Parte do sistema que estou construindo é sobre solicitação de equipamentos (placas de vídeo, memórias RAM, etc), controle de ordens de compra para suprir essas demandas e controle de estoque de equipamentos já disponíveis. Quando houver uma ação para atender uma solicitação, é verificado se os equipamentos solicitados estão disponíveis no estoque, e os que não estiverem ficam separados para entrar em pedidos de compra.
A dúvida é: como mapear o equipamento em si que está no estoque e os requisitos dos equipamentos que estão na solicitação (de forma a poder associá-los) sem ter repetição de código e mantendo uma clareza na estrutura das classes?
Segue o que eu pensei até agora e as respectivas desvantagens.
Primeiro design: Pensei em ter uma classe que representa a solicitação e um dos membros desta seria uma lista de objetos que representam as especificações dos equipamentos. No caso do estoque, este seria composto de objetos de uma classe Equipment.
Problema: as classes de equipamento e de solicitação de equipamento teriam atributos em comum para cada implementação. Ex: solicitação de RAM e memória RAM teriam os atributos de capacidade, barramento, etc em comum.
Segundo design: Haveria apenas uma classe que representaria equipamentos E especificações de equipamentos. Tanto o estoque quanto parte das solicitações usariam o mesmo tipo de objeto.
Problemas: objeto de equipamento deveria ter flag (ouch) para dizer se é uma especificação; Haveria problemas para colocar isso no banco de dados (coloco na mesma tabela? tabelas diferentes com campos iguais?); Teria que ligar duas instancias de equipamentos para indicar que a especificação X foi resolvida com o equipamento Y (talvez um mapa na classe de solicitação?).
Talvez exista algum pattern para resolver isso, ou talvez uma solução adhoc clara, porém ainda não encontrei. Por outro lado, esse caso me parece comum. O que vocês acham? Tem alguma idéia?
Obrigado.
|
|
|
|
Boa tarde!!!
Estou fazendo um sistema em que um agente (serviço em um servidor) deve receber uma requisição para instalar um componente na própria máquina.
Em meu modelo, pensei em ter uma classe que atuaria como um "Gateway" para receber as requisições, ordená-las, direcioná-las, etc. Além disso, criaria classes que implementam uma interface "Component", em que o principal é ter um método "install()", que faria o componente se instalar. Então, o "Gateway" iteraria sobre uma lista de "Component"s chamando o "install()". Isso porque os componentes podem ser COM+, .Net, DLLs, arquivos em geral, etc, e o jeito de instalá-los é diferente.
OK, mas a impressão que tive ao analisar esse modelo é que algo está errado. Isso porque acredito que os componentes não poderiam se instalar, visto que são entidades do sistema. Deveria haver uma classe (ou conjunto de) para instalar esses componentes, só que elas deveriam diferenciar entre o tipo de componente. Outro motivo é que existem partes da instalação que são comuns entre alguns componentes, e eu não consegui uma solução de reaproveitamento nessa arquitetura. Deve haver um ou mais patterns para resolver esse tipo de problema.
Enfim, estou tentando encontrar uma solução melhor, mas como sou iniciante em arquitetura e design patterns (estou começando pelo GOF), estou perdido.
Vocês tem alguma idéia?
|
|
|
|
Muito obrigado pela coleção de links!!!
Mas esse realmente é o único fórum do pessoal que se interessa por design e arquitetura de sistemas? Alguém conhece outros?
[[]]'s
|
|
|
|
andrestrindade,
Sim, é possível. Olhe o eval() no manual, na parte do when.
Sessão 5.8.3: http://docs.jboss.org/drools/release/5.2.0.M2/drools-expert-docs/html_single/index.html#RuleLanguage-ConditionalElements
[[]]'s
|
|
|
|
Puxa vida....
nada a ver com o que eu te expliquei. :]
estou pesquisando no mailing list do projeto para ver se acho alguma coisa, pq eu tbm não sei.
pesquisei se eles tem IRC, mas não encontrei. Ao menos #Dia no Freenode não existe.
vamos ver... se eu descobrir eu posto aqui.
[[]]'s
|
|
|
|
KaosBr,
Então não entendi do que vc está falando.
Primeiramente, vc está falando do programa Dia, (http://projects.gnome.org/dia/) do projeto GNOME, certo?
Segundo: me explique onde está essa "implementação" (que tela, etc), que diagrama vc está querendo fazer, etc.
[[]]'s
|
|
|
|
Recomendo fazer web pois vc n precisa instalar e atualizar os aplicativos em cada máquina que for usar o sistema.
Procure sobre SEAM, Spring, VRaptor, etc. São frameworks bem completos que podem te ajudar. Mas já aviso: se vc n manja nada de EJB, tem que estudar um bocado (estou passando por isso no momento).
[[]]'s
|
|
|
|
wss,
Recomendo que vc estude OO antes de ler este ou outros livros de Java. Vc cometeu erros básicos na hora de escrever o post (como chamar o counter de variável, e achar que na linha 23 uma classe estava sendo criada), e acredito que ler um livro de OO vai facilitar muito a sua vida para depois entender Java, além de que Orientação a Objetos é um paradigma que te ajudará a pensar em arquitetura de sistemas, etc, e não é restrito à linguagem.
[[]]'s
|
|
|
|
KaosBr,
Pelo que eu lembro, essa "Implementação" (um traço com um circulo não preenchido na ponta) é usado em diagramas de componentes para indicar interfaces de comunicação entre os mesmos (subsistemas, módulos, páginas, etc).
Vc usa da seguinte forma: o componente que provê a interface vc liga como uma reta tracejada com uma seta simples até o circulo, ou então com uma reta cheia com um semicirculo na ponta, e a depois vc desenha o círculo e liga com uma reta cheia até a classe que implementa a interface para a comunicação.
Como exemplo bem fácil para entender essa associação, cito a conexão JDBC com um banco de dados. Vc pode identificar o banco como um componente do tipo <<database>> que implementa uma interface chamada JDBC, e depois um módulo do seu sistema que provê a interface, ou seja, utiliza a implementação, e associá-los.
Se eu não me engano, essa notação também pode ser usada em diagramas de classes e objetos. Pesquise sobre isso caso tenha interesse.
[[]]'s
|
|
|
|
|
|