Programação com Objectos/Projecto de Programação com Objectos/Repositório GIT

AVISOS - Avaliação em Época Normal
Esclarecimento de dúvidas: Consultar sempre o corpo docente atempadamente: presencialmente ou através do endereço oficial da disciplina [1]. Não utilizar fontes de informação não oficialmente associadas ao corpo docente (podem colocar em causa a aprovação à disciplina). Não são aceites justificações para violações destes conselhos: quaisquer consequências nefastas são da responsabilidade do aluno.
Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Programação com Objectos): O material de apoio é de uso obrigatório e não pode ser alterado. Verificar atempadamente (mínimo de 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de desenvolvimento.
Processo de avaliação (ver informação completa em Avaliação do Projecto): Datas: 2025/09/24 12:00 (inicial); 2025/10/08 12:00 (intercalar); 2025/10/22 12:00 (final); 2025/10/22 (early bird) 2025/10/23 (normal) (teste prático). Todas as entregas são cruciais para o bom desenvolvimento do projecto, sendo obrigatórias: a não realização de uma entrega implica a exclusão da avaliação do projecto e, por consequência, da avaliação da disciplina. Verificar atempadamente (até 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de avaliação, incluindo a capacidade de acesso ao repositório. Apenas se consideram para avaliação os projectos existentes no repositório oficial. Apenas se considera para avaliação o ramo 'master'. Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório ou de outros materiais, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho. A avaliação do projecto pressupõe o compromisso de honra de que o trabalho correspondente foi realizado pelos alunos correspondentes ao grupo de avaliação. Fraudes na execução do projecto terão como resultado a exclusão dos alunos implicados do processo de avaliação.

Material de Uso Obrigatório
As bibliotecas po-uilib e o conteúdo inicial do repositório GIT são de uso obrigatório:
po-uilib (classes de base) po-uilib-202508310000.tar.bz2 (não pode ser alterada) - javadoc bci-core (classes do "core") (via GIT) (deve ser completada -- os nomes das classes fornecidas não podem ser alterados) bci-app (classes de interacção) (via GIT) (deve ser completada -- os nomes das classes fornecidas não podem ser alterados)
A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio.
Uso Obrigatório: Repositório GIT
Apenas se consideram para avaliação os projectos existentes no repositório GIT oficial. Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho.

Os repositórios GIT para os projectos (um por grupo) já contêm versões iniciais do projecto.

O uso do repositório GIT é obrigatório.

Não serão considerados projectos que não estejam no repositório oficial.

Localização

Os repositórios estão disponíveis no Gitlab da RNL em https://gitlab.rnl.tecnico.ulisboa.pt/leic-a-po25

O conteúdo do repositório pode ser manipulado com o comando git ou com qualquer outro cliente compatível.

Modo de Acesso

O acesso ao serviço GitLab da RNL é realizado com as credenciais IST (à la Fénix)

Todos os alunos do IST têm de ter credenciais válidas para poderem ser avaliados na disciplina.

Apenas é considerado para avaliação o ramo master. Alunos que não coloquem o projecto neste ramo serão excluídos da avaliação.

Para o teste prático é necessário activar os serviços AFS e Shell no self-service da DSI. Sem isso, não é possível completar a avaliação do projecto, reprovando à disciplina.

Conteúdo e Estrutura do Repositório

O código fornecido é de uso obrigatório e deve ser completado.

O projecto é constituído por dois módulos: bci-core e bci-app (o módulo po-uilib é exterior ao desenvolvimento).

Conteúdo inicial do repositório para o módulo bci-core
bci-core ├── Makefile └── src └── bci ├── exceptions │   ├── ImportFileException.java │   ├── MissingFileAssociationException.java │   ├── UnavailableFileException.java │   └── UnrecognizedEntryException.java ├── Library.java └── LibraryManager.java

Conteúdo inicial do repositório para o módulo bci-app

bci-app ├── Makefile └── src └── bci └── app ├── App.java ├── exceptions │   ├── BorrowingRuleFailedException.java │   ├── FileOpenFailedException.java │   ├── Message.java │   ├── NoSuchCreatorException.java │   ├── NoSuchUserException.java │   ├── NoSuchWorkException.java │   ├── UserIsActiveException.java │   ├── UserRegistrationFailedException.java │   └── WorkNotBorrowedByUserException.java ├── main │   ├── DoAdvanceDate.java │   ├── DoDisplayDate.java │   ├── DoOpenFile.java │   ├── DoOpenMenuRequests.java │   ├── DoOpenMenuUsers.java │   ├── DoOpenMenuWorks.java │   ├── DoSaveFile.java │   ├── Label.java │   ├── Menu.java │   ├── Message.java │   └── Prompt.java ├── request │   ├── DoRequestWork.java │   ├── DoReturnWork.java │   ├── Label.java │   ├── Menu.java │   ├── Message.java │   └── Prompt.java ├── user │   ├── DoPayFine.java │   ├── DoRegisterUser.java │   ├── DoShowUser.java │   ├── DoShowUserNotifications.java │   ├── DoShowUsers.java │   ├── Label.java │   ├── Menu.java │   ├── Message.java │   └── Prompt.java └── work ├── DoChangeWorkInventory.java ├── DoDisplayWork.java ├── DoDisplayWorksByCreator.java ├── DoDisplayWorks.java ├── DoPerformSearch.java ├── Label.java ├── Menu.java ├── Message.java └── Prompt.java

Estes módulos podem ser obtidos em conjunto clonando o projecto com o número correspondente à inscrição no Fénix (ver abaixo).

O repositório já tem a seguinte estrutura:

• bci-core (directoria principal da biblioteca com a funcionalidade sem interface com o utilizador)
• bci-core/Makefile (makefile secundária, semelhante à disponibilizada na aplicação bancária)
• bci-core/src (directoria onde reside o código do "core", à semelhança do que acontece na aplicação bancária)
• bci-app (directoria correspondente à aplicação; contém a interface com o utilizador)
• bci-app/Makefile (makefile secundária, semelhante à disponibilizada na aplicação bancária)
• bci-app/src (directoria onde já reside o código da interface textual, tal como na biblioteca equivalente da aplicação bancária)

Esta estrutura já contém algumas classes parcialmente implementadas (bci-core) (que devem ser adaptadas) e outras parcial ou completamente implementadas (bci-app) (algumas das quais não podem ser alteradas).

A estrutura do repositório não pode ser alterada.

O código fornecido em bci-core e bci-app tem de ser completado.

Os nomes das classes fornecidas em bci-core e bci-app não podem ser alterados.

As seguintes classes e interfaces não podem ser alteradas: App.java, todos os Label.java, todos os Menu.java, todos os Message.java, todos os Prompt.java e todas as excepções fornecidas (tanto em bci-core, como em bci-app).

Cuidados a ter na Utilização do Repositório GIT

NÃO FAZER

• git init (não é necessário: o repositório já existe)

FAZER

O repositório já contém uma versão preliminar do projecto e devem ser dados os seguintes passos, para continuar a desenvolver o projecto:

1. git clone git@gitlab.rnl.tecnico.ulisboa.pt:leic-a-po25/prj/123.git (para obter uma cópia local, neste exemplo, do projecto do grupo 123);
2. Editar/adicionar material do/ao projecto;
3. Caso sejam criados ficheiros ou directórios novos, fazer git add ficheiro1 ficheiro2 ... ficheiroN (adicionar novos ficheiros/directorias ao projecto);
4. git pull (antes de enviar alteração locais para o repositório, verificar se há actualizações remotas a incorporar na cópia local)
5. git status (verificar a situação na cópia local e que não foi esquecido nenhum ficheiro importante: voltar a 3. até terem sido todos adicionados)
6. git commit -am "Mensagem de commit." (registar alterações na cópia local)
7. git push (enviar alterações para o GitLab -- sem este passo, não é realizada a entrega do projecto)

Observações importantes

• Não adicionar cópias do material de apoio (po-uilib) ao projecto (serão removidas e quaisquer alterações perdidas -- além disso, lixo no repositório é penalizado).
• Pessoas sem área no AFS, ou sem login activado, não poderão aceder ao conteúdo do teste prático: para activar estes acessos, consultar o self-service do CIIST (DSI) (ver acima). Em caso de dificuldade, consultar atempadamente o corpo docente.
• A estrutura do projecto no GIT deve ser mantida como apresentado.
• Em caso de dúvidas, consultar o corpo docente.

As activações de serviços não são instantâneas: activações no próprio dia de uma entrega ou de uma prova, estão condenadas a falhar e resultam necessariamente em reprovação. A activação atempada é da exclusiva responsabilidade do aluno.

"Receita" para a Entrega de Diagramas UML

Tal como indicado no método de avaliação, os 3 diagramas a entregar -- UML-po-uilib.pdf, UML-bci-app.pdf, UML-bci-core.pdf -- devem ser colocados na directoria uml do projecto no repositório GIT.

Os comandos abaixo explicam como realizar essa operação a partir de um projecto no repositório (desde obter uma cópia local até completar a entrega). O passo de obter a cópia local pode ser omitido se o projecto já tiver sido obtido anteriormente. O passo de adicionar novos ficheiros pode ser omitido se as versões dos diagramas corresponderem a actualizações de adições anteriores. Nos exemplos dos comandos abaixo, 123 é o grupo de trabalho da pessoa a realizar a entrega.

• Obter o projecto do repositório (o projecto fica na directoria local 123). Assume-se que os comandos subsequentes são dados dentro da directoria 123 (notar cd 123 abaixo):

git clone  git@gitlab.rnl.tecnico.ulisboa.pt:leic-a-po25/prj/123.git
cd 123

• Colocar os ficheiros com os diagramas na directoria uml (ficheiros novos ou actualizações). Esta operação depende de onde estão os diagramas ou de como foram digitalizados a partir da versão manuscrita (recorda-se que apenas são aceites diagramas manuscritos, devidamente acompanhados com a declaração de autoria). O comando apresentado é apenas um exemplo (assume que os diagramas estão originalmente na directoria principal do utilizador).

cp ~/UML-po-uilib.pdf ~/UML-bci-app.pdf ~/UML-bci-core.pdf uml

• Adicionar os ficheiros novos ao CVS (no comando a seguir, assume-se que os 3 ficheiros são adicionados, mas pode adicionar-se um de cada vez):

git add uml/UML-po-uilib.pdf uml/UML-bci-app.pdf uml/UML-bci-core.pdf

• Pode realizar-se neste ponto um pedido de actualização da cópia local (caso a outra pessoa do grupo também esteja a fazer alterações -- se não é o caso, este passo é opcional):

git pull
git status

• Registar as alterações (na cópia local) (a mensagem descreve o commit):

git commit -am "Adicionados diagramas UML."

• Finalmente, enviam-se os ficheiros novos para o repositório GIT:

git push