By Marcos Vinicius
Maravilha , finalmente estou chegando ao ponto de bala , sexto termo onde começarei a por a mão na massa , ver as tendências de mercado , me aprofundar mais em JAVA e principalmente em UML.
Como pude concluir a matéria em questão ministrada pelo professor João Bosco é uma continuação da rotina de um projeto , pelo que puder entender em UML eu aprendi a fazer os diagramas , já a fase de projeto é como uma tradução do que esta no diagrama para o código propriamente dito.
A fase de projeto que é a nossa área de estudo no momento nada mais é do que colocar no código fielmente toda a análise dos requisitos contidas nos diagramas, tanto a fase de analise quanto a de projeto estão sujeitas a várias mudanças , mudanças essas que podem ser feitas nas implementações até que se estabilize a iteração.
O projeto baseado em objetos é feito em cima dos diagramas de colaboração e de seqüência , mas primeiramente para um melhor entendimento é preciso se perguntar , para que a utilização deles ?
Primeiramente eu entendo que se um sistema nada mais é do que vários objetos , esses mesmos objetos precisam se comunicar , é aí que entram os diagramas de iteração. É nesses diagramas onde ocorre a troca de mensagens entre os objetos , uma forma de ilustração de como os objetos colaboram entre si com o objetivo de atender os requisitos feitos na análise.
Agora vou falar um pouco dos diagramas de iteração , são dois:
Diagrama de Colaboração – Bom não tenho nada contra a preferência de ninguém , mas eu particularmente prefiro o diagrama de seqüência , pois é bem mais ordenado que o de colaboração , o D.C apesar de ser bem ilustrado não apresenta nenhum tipo de ordenação e sua leitura é bem mais complexa , eu mesmo como aprendiz passaria bem longe dele , mas isso é só uma opinião pessoal minha , a única vantagem que eu vejo nele em relação ao de seqüência é a sua flexibilidade em relação a espaço.
Segue abaixo um exemplo um pouco mais complexo que o apresentado na aula:
Fonte: www.netbeans.org/images/diagram
Diagrama de seqüência: Apesar de não ter muita experiência ainda em diagramas , eu já gosto mais deste , pois a sua organização em raias facilita mais o entendimento e é bem mais simples de se entender , não tem erro , o seu fluxo vai de cima para baixo , da esquerda para a direita , sendo que o seu único problema ao contrario do diagrama de colaboração é o grande consumo de espaço.
Segue abaixo um outro exemplo de diagrama de seqüência , diferente ao apresentado na aula:
Fonte: http://www.ime.usp.br/~kon/MAC5715/2002/DesignFest/M2/diagramaDeSequenciaDeEscolheSessao.jpg
Bom , vou tentar mesmo que errando explicar este diagrama .
A mensagem obterSessoes é enviada para uma instancia de ControladordeSessões só que ao contrário do exemplo da aula , essa mensagem é enviada por um ator “Interface do Jogador”.
O objeto ControladorDeSessões envia uma mensagem obterSessões para o objeto ServidorDeSessões ,este por sua vez envia uma mensagem de retorno “Lista de sessões” ao objeto ControladorDeSessões que por sua vez envia esta mesma mensagem “Lista de sessões” ao ator do sistema “Interface do Jogador” e assim por diante os objetos vão se comunicando através das mensagens enviadas.
Obs: Se houver erro na minha tentativa de explicação , aceito opiniões na boa !!!
Bom já expliquei mais ou menos como funcionam os diagramas , agora vêm a parte de como confeciona-los , e como tudo na vida é baseado em regras , aqui vão umas boas regras para uma boa confecção de um diagrama:
Primeiramente , um diagrama precisa ser bem detalhado , fiel ao que esta sendo proposto no projeto , não pode apresentar falhas e nem brechas , deve consumir cerca de 10% do tempo necessário para iteração e deve ser feito por duas pessoas de preferência , pois como foi dito em sala duas cabeças pensam melhor do que uma, dependendo do tipo de projeto até mais cabeças pensantes seriam bem vindas.
Representando as ilustrações no diagrama:
Como foi visto nos exemplos anteriores , os diagramas possuem classes e instancias, vou representa-las a seguir:
Classe: é representada por um retângulo com o nome da classe em sublinhado.
Maravilha , finalmente estou chegando ao ponto de bala , sexto termo onde começarei a por a mão na massa , ver as tendências de mercado , me aprofundar mais em JAVA e principalmente em UML.
Como pude concluir a matéria em questão ministrada pelo professor João Bosco é uma continuação da rotina de um projeto , pelo que puder entender em UML eu aprendi a fazer os diagramas , já a fase de projeto é como uma tradução do que esta no diagrama para o código propriamente dito.
A fase de projeto que é a nossa área de estudo no momento nada mais é do que colocar no código fielmente toda a análise dos requisitos contidas nos diagramas, tanto a fase de analise quanto a de projeto estão sujeitas a várias mudanças , mudanças essas que podem ser feitas nas implementações até que se estabilize a iteração.
O projeto baseado em objetos é feito em cima dos diagramas de colaboração e de seqüência , mas primeiramente para um melhor entendimento é preciso se perguntar , para que a utilização deles ?
Primeiramente eu entendo que se um sistema nada mais é do que vários objetos , esses mesmos objetos precisam se comunicar , é aí que entram os diagramas de iteração. É nesses diagramas onde ocorre a troca de mensagens entre os objetos , uma forma de ilustração de como os objetos colaboram entre si com o objetivo de atender os requisitos feitos na análise.
Agora vou falar um pouco dos diagramas de iteração , são dois:
Diagrama de Colaboração – Bom não tenho nada contra a preferência de ninguém , mas eu particularmente prefiro o diagrama de seqüência , pois é bem mais ordenado que o de colaboração , o D.C apesar de ser bem ilustrado não apresenta nenhum tipo de ordenação e sua leitura é bem mais complexa , eu mesmo como aprendiz passaria bem longe dele , mas isso é só uma opinião pessoal minha , a única vantagem que eu vejo nele em relação ao de seqüência é a sua flexibilidade em relação a espaço.
Segue abaixo um exemplo um pouco mais complexo que o apresentado na aula:
Fonte: www.netbeans.org/images/diagram
Diagrama de seqüência: Apesar de não ter muita experiência ainda em diagramas , eu já gosto mais deste , pois a sua organização em raias facilita mais o entendimento e é bem mais simples de se entender , não tem erro , o seu fluxo vai de cima para baixo , da esquerda para a direita , sendo que o seu único problema ao contrario do diagrama de colaboração é o grande consumo de espaço.
Segue abaixo um outro exemplo de diagrama de seqüência , diferente ao apresentado na aula:
Fonte: http://www.ime.usp.br/~kon/MAC5715/2002/DesignFest/M2/diagramaDeSequenciaDeEscolheSessao.jpg
Bom , vou tentar mesmo que errando explicar este diagrama .
A mensagem obterSessoes é enviada para uma instancia de ControladordeSessões só que ao contrário do exemplo da aula , essa mensagem é enviada por um ator “Interface do Jogador”.
O objeto ControladorDeSessões envia uma mensagem obterSessões para o objeto ServidorDeSessões ,este por sua vez envia uma mensagem de retorno “Lista de sessões” ao objeto ControladorDeSessões que por sua vez envia esta mesma mensagem “Lista de sessões” ao ator do sistema “Interface do Jogador” e assim por diante os objetos vão se comunicando através das mensagens enviadas.
Obs: Se houver erro na minha tentativa de explicação , aceito opiniões na boa !!!
Bom já expliquei mais ou menos como funcionam os diagramas , agora vêm a parte de como confeciona-los , e como tudo na vida é baseado em regras , aqui vão umas boas regras para uma boa confecção de um diagrama:
Primeiramente , um diagrama precisa ser bem detalhado , fiel ao que esta sendo proposto no projeto , não pode apresentar falhas e nem brechas , deve consumir cerca de 10% do tempo necessário para iteração e deve ser feito por duas pessoas de preferência , pois como foi dito em sala duas cabeças pensam melhor do que uma, dependendo do tipo de projeto até mais cabeças pensantes seriam bem vindas.
Representando as ilustrações no diagrama:
Como foi visto nos exemplos anteriores , os diagramas possuem classes e instancias, vou representa-las a seguir:
Classe: é representada por um retângulo com o nome da classe em sublinhado.
Instância: é representada por um retângulo com o nome da classe em sublinhado precedido de dois pontos.
Mensagens :
Mensagem de retorno: representa uma resposta de um objeto dentro do diagrama de iteração, sendo essa mesma mensagem omitida se for considerada óbvia ou não muito importante.
São indicadas por setas ,essas indicam o fluxo da mensagem dentro do diagrama:
Seta contínua: Mensagem
Seta tracejada: Retorno
Existe um outro tipo de mensagem chamada SELF , onde um objeto "Compra" por exemplo envia uma mensagem para ele mesmo.
Seta tracejada: Retorno
Existe um outro tipo de mensagem chamada SELF , onde um objeto "Compra" por exemplo envia uma mensagem para ele mesmo.
Terminando o assunto até esta 4ª aula chegamos a um diagrama bem curioso , no qual existe uma iteração entre um objeto sobre uma coleção de métodos.
Exemplo:
Fonte: Material de aula do professor João Bosco
Bom , para quem leu e gostou , isso é o que me foi entendido até agora , não deixem de entrar , pois semana que vêm tem mais novidades
abraços a todos !!!!!
Um comentário:
Marcos,
Gostei muito do seu blog, principalmente por que percebo que usou suas próprias palavras. É isso que eu quero.
Gostaria que colocasse o número das aulas a que se referem o texto.
[] Prof. João Bosco
Postar um comentário