É evidente que não vou achar na web alguém que diga qual arquitetura devo usar.
Ex. qdo projeto a ser desenvolvido for para a área da Saúde… use tal ! se for para área imobiliária… use fulana.
Isso eu não vou achar (pois a maioria do pessoal que manja do assunto diz q é necessário contratar um consultor, mas não é o meu caso, é apenas para um artigo), por isso estou postando aqui…
a minha dúvida mesmo é descobrir a diferença entre arquiteturas,
se alguém tiver algum material legal sobre isso ou bibliografia tambem seria bacana.
Cara, a diferença é a seguinte: cada projeto tem uma arquitetura! Você não vai conseguir criar uma arquitetura genérica nunca, você terá que analisar um cenário particular.
E quando digo um cenário particular não estou falando de um sistema na área de saúde somente, como você falou. Não se trata somente da área de atuação do sistema mas de uma série de outros fatores a mais.
Um sistema de saúde com 100 usuários CADASTRADOS certamente tem uma arquitetura absolutamente diferente de um sistema de saúde com 10000 usuários SIMULTÂNEOS, por exemplo.
Se você não escolher um cenário para analisar e um escopo para o seu projeto não vai conseguir chegar a conclusão nenhuma.
Pois então… Os requisitos (tanto funcionais quanto não funcionais) e o escopo é que são a base para definição da arquitetura.
Por exemplo:
Se você tem um requisito que aplicação terá que suportar 10000 acessos simultâneos com certeza terá que se preocupar com escalabilidade horizontal (cluster).
Se você tem uma aplicação web você não poderá usar Swing, naturalmente.
Se você tem uma aplicação desktop não poderá usar Struts.
Enfim, como eu disse anteriormente, você definirá a arquitetura de acordo com o seu escopo.
jeffmor wrote:[quote] Isso eu não vou achar (pois a maioria do pessoal que manja do assunto diz q é necessário contratar um consultor, mas não é o meu caso, é apenas para um artigo), por isso estou postando aqui…
[/quote]Rapaz, se é apenas para um artigo acho que já escreveram o que existe de melhor no assunto vc. tem que ler isso.:
Te garanto que vais mudar teus conceitos e vai parar de inventar história e voltar a estudar/trabalhar.Só um detalhe não vais copiar a idéia alheia, escrever (..sic) o artigo dizendo que o conceito é seu....ok.... :?
ehh willian eu já havia lido e relido esse material do “shoes” (muito bom por sinal)
[quote=WilliamSilva]
Te garanto que vais mudar teus conceitos e vai parar de inventar história e voltar a estudar/trabalhar.Só um detalhe não vais copiar a idéia alheia, escrever (…sic) o artigo dizendo que o conceito é seu…ok… :?
Boa sorte.[/quote]
inventar história? :roll: é conceitual velho, não estou inventando história nenhuma, só estou com dúvidas, e procurando material disponível.
Não sou do tipo de pessoa, de copiar não cara. Se eu for usar o que uma outra pessoa já disse, com certeza eu vou citar.
“Requisito levantado” e “escopo definido” so poem comida no prato de quem finge que ta fazendo alguma coisa. O mundo precisa de software, nao de mais papel com diagramas.
Eu concordo contigo que existem muitas “frescuras” para desenvolver qualquer coisa, mas tem pontos que são fundamentais: entre eles análise de requisitos e escopo, com isso “pronto” a implementação se torna muito mais rápida e precisa…
o intuito:
é debater é sacar conceitualmente as diferenças entre Arquiteturas.
eu posso falar de arquitetura apenas por Design Patterns?
como diria gscordeiro:
se abstrato pudesse ser instanciado, eu diria que esse assunto é a instanciacao da abstração!
Pois é mas são os papéis com diagramas que fazem com que o software possa ser modificado e entendido, sem aquela costumeira bagunça de alguns programadores… deculpa ai… mas vai dar uma estudada no que vc tah malhando…
Saudações a todos … acho realmente interessante os argumentos “extremistas”.
Me pergunto sempre se os desenvolvedores XP, quando um dia pensarem em construir as suas casas ou reformar um apto irão usar das mesmas heurísticas.
Diriam eles ao pedreiro (já que não precisam nem de Arquiteto ou Engenheiro) … “Bota a parede ai mesmo, e não precisa se preocupar com colunas. Se até o final da obra eu resolver fazer o segundo andar da casa, vocês quebram tudo (quer dizer, fazem um refactoring) e constroem tudo de novo.”
[quote=Renatov]
Saudações a todos … acho realmente interessante os argumentos “extremistas”.
Me pergunto sempre se os desenvolvedores XP, quando um dia pensarem em construir as suas casas ou reformar um apto irão usar das mesmas heurísticas.
Diriam eles ao pedreiro (já que não precisam nem de Arquiteto ou Engenheiro) … “Bota a parede ai mesmo, e não precisa se preocupar com colunas. Se até o final da obra eu resolver fazer o segundo andar da casa, vocês quebram tudo (quer dizer, fazem um refactoring) e constroem tudo de novo.”
Abraço.[/quote]
Acredito que os programadores em geral tem um poquinho mais de estudo que os pedreiros em geral (nada contra eles).
Há casas e casas.
Boa parte dos projetos que são descontinuados(ou desencorajados) possuem um dito “Arquiteto de Software” por trás dele.Quer bagunçar um projeto?Taca zilhões de métricas,CMM, uns medalhões(de preferência alguém fera em Análise Essencial e Estruturada que acha que AOO é uma tolice e pode projetar ‘qualquer coisa’ com seu conhecimento).
IMHO, um Arquiteto de Software seria mais uma posição, tipo um indivíduo com + de 5 anos de programação e desenvolvimento de muitos projetos.O Arquiteto apenas como um projetista, um engenheiro, a meu ver é um erro, que pode prejudicar muito um sistema.É como um técnico esportivo de natação que nunca nadou.Existem bons, mas são muito raros…
Realmente essa é uma discussão a lá religião, futebol e mulher. Gera sempre muita polêmica e está recheado de opiniões diversas. Graças a Deus pois a unanimidade é burra.
Bom, fiz analogia a Engenharia Civil devido a nossa área ser a Engenharia de Software (acredito que não foi a toa que qualificaram assim).
O XP é um processo de desenvolvimento que tem os seus méritos e seu valor, mas como diria o Ministério da Saúde: "Aprecie com moderação". Não acredito que ele seja a solução para todos os casos como alguns radicais insistem em apregoar.
Entendo que o XP seja uma boa solução para projetos de pequeno porte e com equipes reduzidas. Principalmente para equipes "in-house" onde o usuário tem a "porta aberta" na área de TI, sem se preocupar com orçamentos, riscos, prazos apertados, tecnologias heterogêneas e em primeiro lugar, em ter os seus requisitos bem definidos. Nessa situação realmente fica fácil iniciar o desenvolvimento de um sistema, e ir adicionando e/ou modificando as funcionalidades durante o decorrer da programação.
