Iteração 2 Design inicial

(1)

Universidade de Aveiro

Departamento de Electrónica, Telecomunicações e Informática

Engenharia de Software

Iteração 2 – Design inicial

Projecto: FX-Center

Grupo: BEDS

David Pacheco (nº 32665)

Cesário Lucas (nº 32773)

Carlos Ferreira (nº 30273)

João Rodrigues (nº 33814)

Data de preparação: 02-04-2008

Circulação: Prof. José Maria Fernandes

(2)

UA-DETI /ES Grupo BEDS, 2008 Página 2

Índice

1 Plano do projecto

3 1.1 Introdução

3 1.2 Organização do projecto

4 1.3 Processo de desenvolvimento

5 1.4 Etapas e objectivos do projecto

5 1.5 Instalação

5

2 Design do sistema

6 2.1 Estrutura de design

6 2.2 Modelo do domínio

7 2.3 Subsistemas

9 2.3.1 Subsistema1 – Multimedia Services

9 2.3.2 Subsistema2 – User Services

10 2.4 Diagrama de classes

11 2.5 Realizações dos Use-Cases

14 2.5.1 Manage Multimedia & Manage Users

14 2.5.2 Add Multimedia

15 2.5.3 Edit Multimedia

15 2.5.4 Add User

16 2.5.5 Edit User

16 2.5.6 Log-in

17 2.5.7 Get YouTube Videos

17 2.5.8 Search Multimedia

18 2.5.9 Configure System Settings

18 2.5.10 Play Multimedia

19 2.5.11 Create Multimedia List

19

(3)

1 Plano do projecto

1.1 Introdução

O estudo prévio do nosso projecto divide-se em duas partes distintas. Neste caso foi necessário primeiro o estudo de requisitos para depois conseguirmos arquitectar um plano de projecto. No estudo de requisitos tentamos conhecer a fundo o que os potenciais utilizadores do nosso sistema estavam à procura num MediaCenter e tentámos acrescentar mais algumas funcionalidades para o distinguir dos outros já existentes. O plano de projecto prolongou-se durante duas semanas onde construímos o diagrama de Casos de utilização, diagramas de actividades e finalmente o diagrama de classes. Juntámos todos estes elementos no relatório da 1ª Iteração e acrescentamos algumas considerações mais específicas sobre o projecto. Esta etapa foi essencial no nosso trabalho pois o sucesso aqui irá determinar o sucesso futuro das fases de construção e instalação. Uma boa fundação aqui permite que o restante trabalho seja apoiado duma maneira muito mais cuidada e quando encontradas dúvidas, estas possam ser rapidamente resolvidas com consulta do trabalho já realizado.

No relatório da 1ª iteração incluímos os requisitos do sistema, um modelo de casos de utilização bem como a descrição dos use-cases principais. Incluímos também a especificação da arquitectura do sistema acompanhada de um diagrama de pacotes da aplicação, bem como um diagrama de deployment com a arquitectura física do sistema.

Prevemos que a segunda parte do projecto referente à construção irá demorar aproximadamente oito semanas. Esta é normalmente a fase mais longa. Tentamos distribuir as tarefas a realizar duma maneira uniforme mas ao mesmo tempo trabalhar em paralelo o mais possível para rentabilizar o tempo. Também tivemos em consideração o número de elementos da equipa disponíveis para a realização do projecto.

Como o CaU ManageMultimedia tem um papel fundamental em todo o projecto e uma prioridade elevada, decidimos começar por este para depois podemos integrar outras funcionalidades nele. Também foi pensado que se houvesse algum atraso na implementação desta funcionalidade, haveria tempo suficiente de margem para se conseguir resolver o problema sem o tempo estabelecido se esgotar. Esta foi outra das razões para que não esperássemos para o final para realizar esta tarefa. É o processo mais longo desta fase, estimado em cinco semanas. Ao mesmo tempo pode-se trabalhar no CaU GetYouTubeVideos pois trata-se duma funcionalidade distinta do resto do sistema e ainda no Log-in que mais tarde podem ser ambas integradas facilmente. O Log-off deve ser implementado depois da implementação do Log-in pois vem na continuação desta última. Tanto o Log-in como o Log-off tem alguma margem para mudanças em termos temporais pois tratam-se de tarefas com menor complexidade que as restantes e têm poucas dependências de outros casos de utilização. O CaU SearchMultimedia vem imediatamente a seguir ao ManageMultimedia no processo de implementação pois sem a possibilidade de manipulação e existência de multimédia, não faz sentido fazer uma pesquisa desta. Também é um processo importante no sistema demorando 3 semanas para a conclusão. Nunca

(4)

UA-DETI /ES Grupo BEDS, 2008 Página 4 poderá vir numa fase anterior à da conclusão do ManageMultimedia. A implementação do CaU PlayMultimedia inicia-se um pouco antes da finalização do processo de criação do ManageMultimedia, permitindo acertar ou alterar alguns pormenores que possam aparecer. Assim como o ManageMultimedia, o PlayMultimedia é uma funcionalidade de elevada utilidade para o sistema e está estimado em 4 semanas. Ao mesmo tempo irá iniciar-se a construção do ConfigureSettings, uma funcionalidade não tão importante mas que irá demorar também 4 semanas, não devido à complexidade que apresenta mas ao tamanho e quantidade de opções que se tem de implementar. Duas semanas antes da fase de implementação terminar, a equipa também irá preocupar -se com o desenvolvimento da criação da lista de multimédia (CreateMultimediaList). Como trata-se duma tarefa simples, a temporização desta pode ser alterada para a frente ou para trás uma semana para conseguir uma melhor distribuição de trabalho (ex. alguma funcionalidade estar mais atrasada ou adiantada do que previsto).

A última fase do nosso trabalho é destinada à instalação. Esta divide-se na instalação do projecto propriamente dito e ainda à formação dos utilizadores. Ambos os acontecimentos não deverão demorar mais do que uma semana. Isto deve -se ao facto do nosso projecto não ter requisitos muitos elevados ao nível de instalação. Como se trata dum sistema que deve ser acessível, em termos de utilização, a qualquer pessoa, foi pensado para ser bastante simples e intuitivo. É um sistema que irá ser utilizado na vida quotidiana pelo mais variado conjunto de pessoas. Assim não é necessária grande formação e a maioria dos utilizadores irá conseguir realizar a maioria das actividades sem ajuda e sem encontrar grandes dificuldades.

1.2 Organização do projecto

A nossa equipa é composta por 4 membros, e procurámos distribuir as tarefas de forma a optimizar o processo de elaboração do projecto da seguinte forma:

Membro Análise de Requisitos

Design e Arquitectura

Implementação Testes Interface Gráfico

David X X X X

João X X

Carlos X X

(5)

1.3 Processo de desenvolvimento

Como metodologia de desenvolvimento iremos usar a OpenUP, sendo o projecto constituído por 5 iterações principais. Iremos procurar ter reuniões semanais de forma a acompanhar o estado do projecto e planear os próximos passos.

1.4 Etapas e objectivos do projecto

Fase Iteração Objectivos Principais Data de Início/ Fim

Inception I1 - Definir a “Visão” do sistema. - Definir requisitos.

- Obtenção dos casos de uso principais e actores do sistema.

- Definição da arquitectura do sistema.

21/02/2008 até 13/03/2008

Elaboration I2 - Refinar os casos de uso - Definir um modelo de domínio. - Design do sistema: Diagrama de classes

13/03/2008 até 17/04/2008

Construction I3 - Implementação inicial - Testes 17/04/2008 até 13/05/2008 Construction I4 - Implementação - Testes 13/05/2008 até 3/06/2008 Transition I5 - Testes - Deploymen t 3/06/2008 até 9/06/2008

1.5 Instalação

Relativamente à instalação do software, pretendemos usar a ferramenta DeployTool incluída no SDK toolkit do J2EE. Esta ferramenta permitir gerir os diferentes componentes do projecto e agrupá -los para enviar para o servidor, sendo a instalação bastante simples e intuitiva.

(6)

2 Design do sistema

2.1 Estrutura de design

Tal como foi referido no relatório da iteração 1, pretendemos seguir uma arquitectura baseada no modelo de 3 camadas e por isso nesta fase do trabalho vamos descrever o nosso plano de design para a camada da lógica aplicacional, mais precisamente o pacote Business Services e a sua ligação com as outras camadas.

(7)

2.2 Modelo do domínio

De seguida apresentamos o mapa de conceitos mais importantes do sistema, ou seja o modelo do domínio, e uma breve descrição das escolhas efectuadas na construção do mesmo:

(8)

UA-DETI /ES Grupo BEDS, 2008 Página 8 Relativamente à construção do diagrama de classes, procurámos utilizar regras para uma boa programação OO. Fazer um mapeamento directo, ou seja, procurar nas especificações de casos de utilização e nos requisitos do sistema substantivos para os nomes das classes. Apesar de por vezes, algumas das classes serem implícitas e retiradas do conhecimento do ambiente alvo, não se encontrando nas descrições textuais.

No que toca ao diagrama de classes em si, existem duas classes que podemos considerar fundamentais, que são a Multimedia e a User, que mantêm uma relação bidireccional, pois um utilizador é dono de um objecto Multimedia, e por sua vez esta tem um User associado. Uma MultimediaLibrary é um agregado de elementos Multimedia. A classe MultimediaLibrary não é uma classe que provém de uma mapeamento directo do sistema, mas sim uma classe “intruso” que decidimos incluir neste modelo devido à sua importância no controlo da aplicação. É também esta classe que requer a interface com o sistema externo YouTube para a pesquisa de vídeos.

A classe User tal como o nome indica representa o utilizador do sistema. O conceito de administrador é representado por um atributo na classe User, pois achámos que não seria necessário criar uma classe para representar os administradores, que seria um subtipo da classe User.

A classe Multimedia mapeia o conceito de elemento multimédia que por sua vez tem um ficheiro associado (classe File) que pode ter vários tipos. No nosso caso os subtipos da classe File são Audio, Video e Image.

A classe MultimediaList representa o conceito de lista de reprodução multimédia, está ligada à classe User (cada utilizador pode ter várias listas de reprodução), e está ligada à classe Multimedia, pois representa um agregado de vários objectos Multimedia.

Relativamente às classes Visualization Settings, Security Settings e System Settings representam os conceitos dos diferentes tipos de definições do sistema. Visualization Settings e System Settings têm uma relação de 1 para 1 com a classe User, pois cada utilizador tem as suas definições de visualização e de sistema. Relativamente à classe Security Settings, esta tem uma relação de 1 para muitos com a classe User, pois todos os utilizadores têm as mesmas definições de segurança, sendo que estas apenas pode m ser alteradas por utilizadores administradores.

(9)

2.3 Subsistemas

Nesta secção iremos mostrar o design de classes para cada um dos subsistemas do pacote principal Business Services. Iremos mostrar um diagrama de classes por cada pacote, para uma melhor compreensão, e no final o diagrama de classes completo, bem como a explicação para a escolha de alguns padrões de design usados.

2.3.1 Subsi stema1 – Multimedia Services

(10)

UA-DETI /ES Grupo BEDS, 2008 Página 10 Neste pacote que engloba os serviços virados para a gestão de Multimédia, as classes usadas já foram consideradas anteriormente no modelo do domínio, bem como o porquê da sua utilização. De destacar a classe Multimedia Library, que é uma classe “intruso” que não faz parte do domínio do sistema, mas é sim uma classe do domínio do software que faz o controlo das operações importantes dos casos de utilização relacionados com as operações sobre elementos multimédia, e serve portanto de interface a este pacote.

De notar também a classe de enumeração MultimediaType, que foi criada para representar apenas os diversos tipos de elementos multimédia, para facilitar a identificação do tipo dos objectos Multimedia sem ter que aceder ao objecto File correspondente.

Neste pacote aplicámos portanto o padrão de desenho “Facade”, pois a classe MultimediaLibrary providencia uma interface para as classes fora do pacote principal Business Services poderem aceder aos diferentes serviços dentro do pacote Multimedia Services.

2.3.2 Subsi stema2 – User Account Services

(11)

UA-DETI /ES Grupo BEDS, 2008 Página 11 Relativamente a este pacote de classes que trata das operações relacionadas com os utilizadores, foram usadas as classes User, MultimediaList, SystemSettings, VisualizationSettings e SecuritySettings, já incluídas também no modelo do domínio. Foi criada uma classe UserApp, que tal como a classe MultimediaLibrary do pacote anterior é uma classe “intruso” que provém do domínio do software, e que foi criada com o objectivo de controlar as acções relativas aos casos de utilização que envolvam a gestão de utilizadores, log-in e log-off.

Em relação a padrões de desenho, foi o usado o padrão Singleton para a classe UserApp, ou seja, pretendemos que exista apenas uma instância desta classe para controlar as operações dos utilizadores.

2.4 Diagrama de classes

A junção destes dois pacotes, dá origem ao diagrama de classes do pacote Business Services, que por obviamente ser um diagrama mais complexo decidimos separar nos dois diagramas de classes anteriores para uma melhor compreensão. De seguida iremos apresentar o diagrama de classes principal, bem como explicar a forma de como o pacote Business Services se interliga com os restantes pacotes da arquitectura através das classes de interface apresentadas também no diagrama. De notar ainda que neste diagrama de classes não estão presentes os métodos get e set necessários de cada uma das classes apenas por questões de simplificação do diagrama, pois implicitamente nós consideramos que estes se encontram nas classes.

(12)

(13)

UA-DETI /ES Grupo BEDS, 2008 Página 13 Tal como se pode observar pelo diagrama, este representa uma junção dos dois diagramas de classes dos pacotes Multimedia Services e User Services. É de notar também a inclusão das classes de interface com os restantes pacotes (parte inferior do diagrama).

A interface iFXDataBase fornece os métodos necessários à interacção com o serviço de dados persistente, “escondendo” as funções deste mesmo sistema, qualquer que ele seja. Ou seja, a função que implementar esta interface deve chamar as funções da API do serviço de dados persistente, tornando-as transparentes para o programador da camada lógica (pacote Business Services).

A interface iYouTube fornece os métodos para a interacção com o sistema externo YouTube. A classe que implementar esta interface lida directamente com a API Google Data (que é fornecida pelo sistema externo) para realizar as funções. Neste momento a interface apenas inclui o método de pesquisa, pois a API Google Data apenas permite a pesquisa de vídeos, e não permite o download dos mesmos tal como pretendíamos inicialmente. Por esse motivo, a funcionalidade do download de vídeos encontra-se neste momento em “standby” até encontrarmos alguma solução possível e legal para esta.

A outra interface presente, UI fornece os métodos para a interacção directa com o interface com o utilizador e que por sua vez acede às classes “intruso” Multimedia Library e UserApp que fazem o controlo da lógica da aplicação. Neste momento esta interface ainda não tem métodos, pois a interface com o utilizador ainda se encontra em fase de estudo. A classe que implementar esta interface é responsável por implementar os métodos que permitam mostrar os mais variados elementos internos da aplicação ao utilizador (por exemplo: Listas de reprodução, Listas de elementos Multimédia encontrados, etc).

Cada uma destas interfaces apresentadas representa a ligação com cada um dos pacotes do diagrama da arquitectura que ainda não tinham sido referidos. A inter face iFXDataBase representa a ligação com o pacote Data Services, ou seja as funções relacionadas com o serviço de dados persistente. A interface UI representa a ligação com o pacote UI, ou seja as funções disponíveis para a interacção com a interface com o utilizador. E finalmente a interface iYouTube que faz a ligação com o pacote do sistema externo YouTube Services.

(14)

2.5 Realizações dos Use-Cases

Nesta secção iremos apresentar os casos de utilização refinados da iteração anterior, bem como os diagramas de sequência que demonstram as interacções entre os diferentes objectos durante a realização do cenário principal de execução dos use-cases.

2.5.1 Manage Multimedia & Manage Users

Na 1ª iteração apresentámos o diagrama de casos de utilização e considerámos dois casos que eram o Manage Multimedia e Manage Users, e que englobavam os processos de adição, edição e remoção de multimédia e utilizadores. Nesta iteração decidimos analisar com mais pormenor estes casos de utilização devido à sua importância, tal como é apresentado no diagrama abaixo. De seguida, vamos apresentar os diagramas de sequência dos casos de adição e edição, tanto de Multimédia como de utilizadores pois são os processos mais complexos. O caso de remoção é um processo simples em termos de interacção entre objectos, ao qual achamos que não é necessário apresentar o diagrama de sequência.

(15)

2.5.2 Add Multimedia

Diagrama 7: Adição de novos elementos Multimédia: Diagrama de Sequência

2.5.3 Edit Multimedia

(16)

2.5.4 Add User

Diagrama 9: Adição de novos utilizadores: Diagrama de Sequência

2.5.5 Edit User

(17)

2.5.6 Log-in

Relativamente ao caso do Log-in o caso de utilização mantém-se com o mesmo grau de detalhe tal como especificado na 1ª iteração, sendo que no seu cenário básico tenha o seguinte diagrama de sequência:

Diagrama 11: Log-in de utilizadores do sistema: Diagrama de Sequência

2.5.7 Get YouTube Videos

Relativamente ao caso Get YouTube Videos apresentamos o diagrama de sequência para o caso básico da pesquisa de vídeos YouTube:

(18)

2.5.8 Search Multimedia

De seguida apresentamos o diagrama de sequência para um cenário básico do caso de utilização Search Multimedia, em que o utilizador pesquisa, cria uma lista de reprodução e reproduz os ficheiros encontrados.

Diagrama 13: Pesquisa e reprodução de conteúdos multimédia: Diagrama de Sequência

2.5.9 Configure System Settings

(19)

UA-DETI /ES Grupo BEDS, 2008 Página 19 Tal como nos casos de utilização Manage Users e Manage Multimedia, achámos importante especificar mais em pormenor o caso de utilização Configure System Settings nesta iteração. O diagrama de casos de utilização para as configurações de sistema é apresentado acima, e basicamente inclui os 3 casos de edição dos 3 tipos de definições de sistema. De seguida apresentamos o diagrama de sequência do cenário básico de configuração de opções. Este diagrama acaba por ser genérico para os 3 casos de configurações apresentados acima no diagrama de casos de utilização, pois o único elemento que varia é o objecto que representa as configurações em questão (SystemSettings, VisualizationSettings, SecuritySettings).

Diagrama 15: Alteração das configurações de sistema: Diagrama de Sequência

2.5.10 Play Multimedia

Relativamente a este caso de utilização, não procedemos a nenhum refinamento, e não incluímos nenhum diagrama de sequência. A não inclusão do diagrama de sequência deve-se ao facto de a maior complexidade no cenário básico do caso de uso Play Multimedia, ser a operação de pesquisa, que é uma extensão deste caso e se encontra demonstrada no diagrama 13 (Search Multimedia).

2.5.11 Create Multimedia List

No que toca ao caso do Create Multimedia List decidimos fazer uma especificação mais detalhada, incluindo os casos de gravação e carregamento da Multimedia List de um ficheiro. O seguinte diagrama de use-cases demonstra estas operações.

(20)

Diagrama 16: Criação ou Gravação de Multimedia List: Diagrama de Use-Cases

A operação da criação da Multimedia List em si é bastante simples, pois consiste apenas na selecção de elementos Multimedia e na sua submissão para o sistena. Por outro lado os casos de gravação e criação a partir de ficheiro já efectuam operação mais complexa, e por isso de seguida apresentamos os diagramas de sequência destes dois casos.

(21)

Diagrama 18: Carregamento do conteúdo de uma Multimedia List a partir de ficheiro: Diagrama de Sequência

(22)

3 Plano da próxima iteração

 Implementar o código das core classes do sistema.

 Direccionar o esforço da implementação para os Use-Cases prioritários, tal como especificado no plano de projecto descrito no capítulo 1 deste relatório.

 Escrever testes básicos do JUnit para o código implementado, e garantir que o código passa estes testes, pelo menos os mais básicos.