Oi Tatiana,
Estou precisando da ajuda de pessoas que conheçam a fundo a interface do InVesalius, e ninguém menos do que você e o pessoal aí de Campinas para me dar aquela "ajudinha". O problema é o seguinte: temos que elaborar um diagrama de objetos para a aplicação, definindo para tanto, alguns temas específicos. Estes temas representam domínios que agregariam as operações de forma coerente de acordo com as suas funcionalidades. Eu pensei em desmembrar o InVesalius em dois temas: Visualização do Modelo 3D e Geração do Modelo 3D.
Eu fiz um esboço do diagrama de objetos direto na UML (diagrama de classes), e gostaria que se fosse possível, que você me desse ao menos ajuda na definição destes temas ... Você acha que esta definição que fiz faz sentido!? Ou eu poderia desmembrar o software em mais partes? E quais partes seriam essas?
Ainda não dei nome nem para as relações, então é realmente um esboço ... é que estou meio perdido ... se você ou a galera aí puderem me dar essa força eu agradeço desde já!
A idéia é que se possa construir um modelo do software de forma que sirva como um "mapa" da aplicação, sendo possível inclusive mapear quais seriam as partes do software afetadas em uma possível futura alteração.
O modelo de objetos foi construído com base nas entidades observadas no modelo de operações, sendo que estes dois documentos, assim como um esboço de manual para o usuário do programa, encontram-se disponíveis no seguinte endereço: http://www.softwarepublico.gov.br:/dotlrn/clubs/invesalius/file-storage/?package_id=626894&folder_id=4579275
Além do processo de Engenharia Reversa temos que propor uma Reengenharia para o sistema, a fim de validar o processo completo de portabilidade da aplicação, e para tanto iremos primeiro avaliar o impacto que as bibliotecas utilizadas apresentaram quando migradas para ambiente GNU-LINUX. Assim, temos que efetuar um levantamento das bibliotecas e verificar quais as possíveis dificuldades que existirão neste processo. O Thomaz está fazendo o levantamento, e caso surjam dúvidas entraremos em contato.
Grato pela atenção!
Ivo Rafael Santos Menezes
Autor: Ivo Rafael Santos Menezes
44 comentários
(a) quais documentos e diagramas teremos ao fim do projeto?
(b) qual é a finalidade de cada documento e diagrama? Com base no que você mandou, tentei esclarecer estas questões. Por favor, corrija as informações, dado que não conheço o método Fusion. 1. Documento - Funcionalidades InVesalius 2.0
funcionalidades_invesalius_2.0.17_v1.doc
Descrição das funcionalidades do programa, semelhante a um manual de usuário. 2. Documento - Modelo de Ciclo de Vida
modelo_de_ciclo_de_vida_v1.doc
O escopo de cada uma das funcionalidades descritas no documento "Funcionalidades InVesalius 2.0" - quando determinada função inicia e quando termina. 3. Documento - Modelo de Objetos
modelo_de_objetos_v1.doc
Definição e caracterização de temas que agregam operações do programa de modo coerente com suas funcionalidades. 4. Diagramas
diagrama_geracao_modelo_3d_v1.jpg
diagrama_visualizacao_modelo_3d_v1.jpg
Esboço dos temas a serem abordados no modelo de objetos (3). Considerando que as definições acima estejam corretas, tenho algumas sugestões. Para os documentos 1 e 2 acho que um pré-requisito é listar as funcionalidades do sistema. Com isso fica mais fácil estudarmos e avaliarmos os documentos. (c) Você poderia fazer uma lista destas funcionalidades? Aí já serve de índice para o documento. No que diz respeito ao documento 3 e aos diagramas do item 4, não acho que esta organização seja adequada... [Ivo] Eu fiz um esboço do diagrama de objetos direto na UML (diagrama de classes), e gostaria que se fosse possível, que você me desse ao menos ajuda na definição destes temas ...Você acha que esta definição que fiz faz sentido!? Ou eu poderia desmembrar o software em mais partes? E quais partes seriam essas?
Faz sentido, mas acredito que não é adequada... Sim, poderia desmembrar o InVesalius em mais partes. Fiz alguns comentários com base nos diagramas que você enviou. Disponibilizei em:
analise_diagrama_criacao_modelo.pdf
analise_diagrama_visualizacao_modelo.pdf No caso do segundo diagrama, ao invés de comentar em cima dele, resolvi fazer um esboço do que o InVesalius seria, com as funcionalidades e os tipos de dados manipulados, para a gente tentar estruturar melhor os conceitos, e para servir de orientação geral para esta etapa de determinação de temas. Penso que poderíamos partir do arquivo analise_diagrama_visualizacao_modelo.pdf para definir o que, neste contexto, poderia ser um tema. (d) Não entendi direito o que define um tema... Até que ponto deve-se abstrair e como o tema se relaciona as funcionalidades? Abraços, Tatiana
Modelo de Ciclo de Vida (Apresentação de características da interface através da produção de expressões regulares - será utilizado também na fase de Reengenharia, forncendo-nos uma forma de validação das funcionalidades portadas para o ambiente GNU-LINUX);
Modelo de Operações (Apresentação detalhada das funcionalidades verificadas a partir do Modelo de Ciclo de Vida - este documento poderá ser utilizado também na hora de validação das funcionalidades portadas, uma vez que teremos que efetuar verificação de características das operações funcionais que sejam apresentadas como produto final);
O método Fusion propõe a presença do modelo de objetos, que seria uma forma de mapear o software através de temas. Os temas representam domínios aplicáveis ao software. Seriam características que o definem, e assim definem a sua divisão, modularização etc ... A proposta de nossa orientadora é que nesta fase seja produzido um diagrama de classes, utilizando a UML (o método possui outra forma de modelagem), de forma a apresentar um raio-x da aplicação. A idéia é que este diagrama, além de colaborar na proposta de reengenharia do sistema, sirva de auxílio para futuras alterações no código do InVesalius. Tentar efetuar um diagrama de forma consistente na tentativa de se prever quais partes do software seriam afetadas por alterações vindouras. Do método Fusion em si seriam estes os documentos. Na fase de Reengenharia ainda surgiriam outros documentos, tais como o mapeamento das bibliotecas utilizadas na aplicação, quadros de alterações necessárias para a portabilidade do sistema, etc. Nada muito sofisticado. Não sei se acrescentei muita coisa não, mas foi o que me veio na cabeça agora. No momento estamos (eu e a Carol) escrevendo algumas partes formais do trabalho, tais como definições do tema de engenharia reversa, apresentação e introdução do projeto, motivação, tópicos relacionados a reengenharia e por aí vai ... O Thomaz está efetuando o mapeamento das bibliotecas (necessário para que possamos efetuar uma proposta de reengenharia), e "tomando conta" da parte relacionado ao código propriamente dito. Sempre que possível vou tentar te mater informada! É isso! Grande abraço e até a próxima!