| Autor |
Mensagem |
|
|
Não gosto muito de ensino a distancia. A obtencao de conhecimento é muito dinamica, como voce pode fazer um MBA a distancia? Isso nao existe, nem somente em faculdade voce consegue aprender muito, a maioria dos cursos te mandam para empresas por alguns meses, as vezes até em outros paises.
Bom, é seu gosto pessoal. Acho que a maneira que eu coloquei foi muito determinante! Mas já vou consertar: realmente nem todo curso dá para fazer à distância com a mesma qualidade, mas um curso que dá para fazer à distância (como o nosso de Casos de Uso) teria o mesmo valor acadêmico que um curso presencial... Nosso curso de Levantamento e Especificação de Requisitos não daria para fazer on-line com a mesma qualidade do presencial (simulamos uma reunião com o cliente no curso, não seria a mesma coisa fazer via net.)
Tambem nao acho que provas não provam nada. Acho que as provas não dizem tudo, mas provam alguma coisa sim.
Provam muito pouco. Teve alguma prova que você fez e o professor te deu um feedback pessoal, discutindo os pontos que você está tendo dificuldades, permitindo que você corrija os erros e REALMENTE aprenda? O estudo em universidades é em atacado: faça a prova, se passou parabéns, senão, volta e faça de novo.
Eu fiz um curso a distancia de frances, com todas as ferramentas possiveis, por 3 meses. Apos isso, tentei um professor normal. Cara, o negócio rendeu 1000% mais que o curso a distancia.
Vc está comparando curso com aula particular... aí é covardia... já comentando, ele aplicava provas? No meu caso não dá para dar aula particular sobre desenvolvimento de software. Apesar que agora, discutindo com você, acho que até deve ter mercado para dar aulas particulares de Word, Excell, Windows... já tó dando uma dica para quem quiser ganhar aí uns 30-40 reais hora num negócio bem fácil...
|
 |
|
|
Ensino a distância é válido. É uma realidade no mundo todo e por incrível que pareça, já tem mais de 100 anos no Brasil.
Não é só uma questão de "material, leitura e fóruns". O ensino à distância pode chegar aonde a sala de aula não chega. Nosso curso on-line tem inscrições até em Angola, Portugal. Quem mora em grandes centros urbanos não tem tanta dificuldade e pode escolher, mas certas regiões do país não tem tanta oferta e os cursos via internet são interessantes.
Eu vejo que o curso à distância tem o mesmo valor educacional que um curso presencial, e não tem muito a ver com a "disciplina" do aluno, mas sim com a sua vontade de aprender. Para mim, se o aluno vai para a sala de aula desmotivado, dá uma estudadinha e tira a nota para passar na matéria ele não está aprendendo, fazer o curso não é garantia que o aluno aprendeu. Prova não prova nada.
Mas o curso on-line deve ser atraente, o negócio tem que atrair o aluno, desafiá-lo! O ensino on-line realmente é um desafio que muitos educadores não estão prontos. Prender a atenção de um aluno em sala de aula já é um desafio, agora fazer isso via internet é um desafio maior ainda. O material muda, o formato do ensino muda, a maneira que você expõe o conteúdo muda!
Fazer um curso on-line que funcione não é um negócio fácil e nem barato. É preciso muita dedicação e "reaprender a ensinar". Existem muitos formatos de cursos à distância, desde via correio como o Instituto Universal Brasileiro (lembra dos anúncios nos gibis?) como um ambiente de ensino à distância via internet como o que temos na ASPERCOM.
|
|
|
|
cissosaito,
O software por sí só é um "ser inanimado", isto é, não funciona sozinho. O M$-Word, sozinho não consegue produzir texto, precisa do ator para digitar as letrinhas.
O ator é alguma coisa externa ao sistema que possui responsabilidades fora do controle do próprio sistema. 99% dos casos o ator será uma pessoa ou um sistema externo (integração entre sistemas).
Seria legal você fazer o nosso curso on-line grátis como ponto de partida. Cadastre-se e acesse: www.aspercom.com.br (recomendo a lição 2, onde tratamos esse assunto).
Pode ocorrer de ter uma classe com o mesmo nome de um ator, mas a classe é interna à responsabilidade do sistema, o ator não!
|
|
|
|
A relação entre DBAs e o Hibernate é péssima, pois IMHO DBAs estão perdendo bastante terreno atualmente. Alguns projetos que trabalhei onde os DBAs ficaram responsáveis pelo mapeamento OO->ER deu muitos problemas, pois os DBAs ficavam inventando histórias no mapeamento para fazer aquelas famosas justificativas: -"mas quando esse indice alcançar mais de 5 alocamentos de disco lá pelo ano de 2046 a performance ficará comprometida em 2 ms".
Você só teria um impedimento ao uso do Hibernate se por acaso os DBAs da sua empresa não permitirem o uso de queries diretas (SELECT/INSERT/UPDATE/DELETE), permitindo apenas stored procedures.
Se o sistema está baseado em stored procedures, realmente perdemos um ganho significativo no uso do hibernate, que é a independência de banco de dados. Associar perfis de segurança ao banco também não é uma boa idéia, mas acontece muito em inst. financeiras. Função do banco é guardar dados.
Nos meus últimos projetos, o hibernate tem caído como uma luva. Alguns com mais de 300 tabelas não tive problema algum. Nem precisamos mais de modelagem de dados tipo MER. Nossa visão dos dados acaba sendo as próprias classes. Um modelo de classes já nos é suficiente. Nem precisamos do MER, nem sentimos falta. Aliás, nem escrevemos os scripts de geração do DB. O schemaexport resolve.
|
|
|
|
Na aba Scenario das propriedades do Caso de Uso vc consegue escrever o texto do caso de uso e depois gera um documento Word através do "Rich Text Documentation". É melhor do que ter conteúdo fora da ferramenta. Mesmo assim, o EA não é poderoso para gerência de requisitos.
OK?
|
|
|
|
Sempre essa eterna discussão e ninguém respondeu o tiago! 
Cara, essa situação é ruim, pois você terá que ter um RemoteFaçade, já que é "distribuído". Um mesm façade pode resolver a situação montando ou desmontando esse DTO (acho que existe um "pattern" que se chama "Assembler", bom, independente do nome, a idéia é fazer um DTO virar um Entity ou algo do tipo, certo?).
Não teria problemas se o seu Helper acessar esse façade, mas certifique-se que ele só possui regras de apresentação (só manuseia o DTO e não Entities).
Espero ter ajudado...
|
|
|
|
Taz wrote:
É comodo para os profissionais pq não precisam estudar muito;
Só não é comodo para o cliente que paga a conta de um projeto que, no final, poderia ter saído pela metade do tempo com metade dos recursos
Não estou muito certo de que o Manifesto Ágil vingue no Brasil.
Não vai ser "pra sempre" que os clientes vão pagar 3.000 horas para qualquer sisteminha departamental. O mercado já está acordando para isso.
O Manifesto só não pega mais por que os profissionais não estão preparados (não dá para tratar um desenvolvedor recém-formado "as serious people" [Ambler], salvo raras exceções).
Também não pega porque o cliente não quer se envolver [Beck]. Trabalho em fábrica a mais de 7 anos, é mais do que comum o cliente jogar o projeto no nosso colo e ir viajar para a europa e quando voltar quer o sistema rodando.
|
|
|
|
Taz wrote: o cara que implementa tb deve ser apto a coletar requisitos.
Convenhamos que não é algo que se encontra fácil no mercado...
|
|
|
|
Casos de Uso são independentes de tecnologia. O ator é alguém que tem um objetivo com relação ao sistema, casos de uso são requisitos, não importando o que está "atrás". Trecho tirado da apostila da ASPERCOM:
"Aquilo que é responsabilidade interna do sistema não pode ser extraído como Ator".
Se seu ator está efetuando uma funcionalidade no dispositivo móvel, para ele não interessa se está conectado a um Tomcat, Jerrymouse, JBoss, JEmpregado, nem se é via WiFi ou transmissão de pensamento. Casos de Uso mapeiam o problema e não a solução.
Recomendo o nosso curso. Lição 2.
|
|
|
|
Então fazemos do mesmo jeito... . Concordas que é o pulo do gato que a partir disso já dá para gerar os POJOS e direcionar o desenvolvimento?
O ponto de vista que sou contra é um "Domain Model de Negócio", feito por um Analista de Negócio e com classes incodificáveis e que o processo nos exige manter uma rastreabilidade como se os conceitos fossem mais válidos que os Dez Mandamentos.
Não sei se você já passou por uma experiência irritantíssima como essa.
|
|
|
|
Eu já falei... eu não faço... diagrama de classes pra mim é um domain model implementável (AKA, entities, value-objects, repositories, services), trabalho de um analista de sistemas, não de negócio... Desses elementos eu gero código, que me poupa o trabalho e também me permite uma reversa código-modelo um pouco menos traumática.
Meu ponto de vista: Não acho uma boa idéia "Classe de Negócio Pedido de Vendas" e depois "Classe de Implementação PedidoVendas" (foi o que comentei a respeito de uma dependency <<refine>>).
Como foi a sua experiência interesantíssima? Partiu de um diagrama de classes de negócio com classificadores tão abstratos que não se traduzem em código nem a pau?
|
|
|
|
Errr... vamos deixar mais claro....
Digamos que sua estrutura de dir seja:
C:\projeto\classes\br\com\teste\sistema\ClasseXPTO.class
então o Hibernate.cfg.xml:
C:\projeto\classes\Hibernate.cfg.xml
Esqueça esse CONFIG_FILE_LOCATION, meu HibernateUtil e o de milhões no mundo inteiro é assim:
|
|
|
|
Taz, como vcs fizeram isso? Esse refinamento era :
a) evoluir as classes de negócio para classes de implementação no mesmo diagrama
b) deixar as classes de negócio intocadas e usar a "maravilhosa" dependência <<refine>> criando uma nova classe de implementação em outro diagrama
Vamos avaliar nossas IMHO... 
|
|
|
|
Acho que ele tem que estar no raiz do seu /classes ou /bin. Sempre deixei lá e nunca tive problemas...
|
|
|
|
Só complementando, é na investigação da interação que você descobre responsabilidades (comportamentos, operações, métodos), não no diagrama de classes. Diagrama de classes é mais utilizado para descobrir a estrutura estática do sistema (Classes, Atributos e Associações). Para analisar a parte dinâmica (conversa entre as classes) é melhor utilizar um diagrama de sequência.
|
|
|
|