Bom dia!
Estava fazendo uma pesquisa no forum mas não consegui encontrar respostas para minha dúvida 
Então vamos lá…
Sobre a docomentação que deve ser trabalhada na parte de projeto de sistemas oo, o que se constuima entregar? Por exemplo diagramas de sequencias com todas as classes participantes de um caso de uso que use o padrao MVC, e se usarmos EJB, devemos representar por exemplo as sessoes? Na parte de projeto ainda, matamos os DED´s da vida e utilizamos Diagramas de classes para representar as persitências?
Este é apenas o começo de outras dúvidas!!
Um abração,
Depende …
Acho que as opções válidas são …
- o que o cliente especificar
- o que o projeto precisar
- o que estiver especificado no processo de sua empresa (no caso de uma empresa CMM x , quanto maior o x , mais burocracia)
quer uma dica
leia agile modeling que vai te dar uma idéia muito boa de como fazer 2)
falow
Valeu pelo link Rodrigo…
Cara, a parada é a seguinte (leva a mal não carioca fala assim hehehe)…
A minha dúvida é mais no nivel de abstração. Imagina o seguinte, você tem que fazer a analise… Beleza… Faz os digramas de caso de uso, de sequencia,classe,etc…
Ai, você já tem tudo modelado, só que agora vc precisa passar a bola para frente, a galera da implementação vai cair de emcima e se virar para desenvolver o que você analisou…seria a fase de projeto, certo?
Pois, é , nesta fase de projeto é que tenho cá minhas dúvidas e que continuam…
Por exemplo, para entregar ao dba o modelo de banco, que que você usa?
Para o cara fazer as telas, a interface gráfica, o que você usa? o que entrega?
Tem mais, tipo ainda na tela , vc sabe que deve ser mostrada uma lista de estados por exemplo, que deve ser uma combo por exemplo… aonde vc registra isto?
Sentiu, to com um problema de abstração de informação para repassar aos outros membros da equipe…
Não, é implementação
O grande ponto é que dependendo do lugar existe ou não uma distinção grande entre as ‘fases’, e em casos de metodologias ´geis isso pode ser muito menos formal.
O que ele pedir 
Casos de uso e uma descrição do que preciso, mais o que ele pedir
O problema não é abstração, você está formalizando demais o processo. Se o lugar onde você trabalha é assim, deve ter um ‘DEPARTAMENTO DE FORMULÁRIOS AZUIS’ onde você acha este tipo de coisa [se não, procure no de FORMULARIOS VERMELHOS], se vocês aidna não trabalham assim, pergutne aos outros envolvidos o que eles precisam, tente manter o mínimod e documentação fluindo, visto que estas coisas costumam ficar defasadas em minutos, e causam um gasto extra desnecessário.
[]s
Com certeza, não da para ficar criando muito documento!
Mas, queria padronzar um mínimo… Tomando ainda como exemplo aquilo que coloquei. O DBA vai te pedir um DED, e você como projetista, ela não precisa saber sobre mecanismos persitentes, se você vai usar hibernate ou ejb, o que ele vai precisar é saber quais as classes viram tabelas, certo?
Sei lá, acho que o webdesigner vai precisar de um documento (diagrama de sequencia acho que foi a melhor coisa que descobri) que vai mostrar para ele a interação…
Quanto ao meu projeto,ele esta apenas engatinhando, e na verdade estou estudando os artefatos(palavra bonita né) que devem aparecer em cada interação.
Mas valeu pelas dicas, ahh… já li muito dos seus posts!
[]s
este lance de “Analise” e “Projeto” eh coisa do Unified Process… nao?
Nao conheco mto bem o UP mas me parece que na fase de analise do UP eh feito o levantamento de requisitos, casos de uso e etc. Existe ateh um diagrama de classes para a fase de analise. Neste diagrama tu nao define os mehtodos e tal. Soh os atributos.
Na metodologia do Larman ele define mto bem estas fases … mas eh soh mais uma metodologia de desenvolvimento de softwrae OO.
Isso nao eh realmente necessario …
[]s!Não. A Análise e Projeto de Software surgiram com a programação estruturada, sob influência de Yourdon, deMarco e cia.
Existem mutias definições conflitantes, mas basicamente eu entendo assim:
Análise (System Analysis) - Define o minimundo do sistema, analogia semrpe usada: define “o quê”, não como
Projeto (System Design) - Define e especifica os componentes do sistema de software, define “como”.
[]s
Joao,
com certeza o UP tem estas fases, de analise e projeto. Mas eu não estou muito preocupado com a linha de processo que estou seguindo. Não sei se você já participou do desenvolvimento em equipe(grupo) de um software.
Toda vez que temos este tipo de interação, de mais do que uma pessoa participando do projeto e desempenhando “papeis” diferentes, fica muito complicado, passar informações não padronizadas para o cara que vai realizar um trabalho que depende do trabalho que você fez. Isto, o UP classifica com artefatos. Existe uma troca de artefatos entre os membros da equipe, só que o maior problema, na prática e saber qual o nivel de abstração que você tem que descer. Isto, acho que é uma questão de felling, só com o tempo que vamos conseguir ter. Por enquanto eu nao tenho este felling ainda!
Quem tiver POR FAVOR nos ajude! :shock: