II. Elementos a Apresentar

Transcrição

1 Projecto da Disciplina de Programação Orientada Por Objectos 2004/2005 Programação Orientada por Objectos (Cursos: EII EIG EEC) Projecto 2004/2005 I. Considerações Gerais Pretende-se com este projecto a concepção e desenvolvimento de uma aplicação especificada no ponto III, segundo os paradigmas da análise, desenho e programação orientada por objectos, tendo por suporte metodológico a UP (Unified Process) modelada em UML e implementada em JAVA. Cada projecto deve ser elaborado em grupos de dois alunos. A aplicação da metodologia UP deverá necessariamente contemplar duas iterações. Uma na fase de Concepção e outra na fase de Elaboração. Na modelação deve considerar-se as tarefas subjacentes aos workflows definidos nas iterações do UP e a produção dos correspondentes artefactos. Não existem restrições quanto às características e/ou particularidades das linguagens UML e JAVA a utilizar, sendo deixado ao critério do analista/programador qualquer pormenor de implementação não seja referido no enunciado. Todos os trabalhos deverão ser obrigatoriamente impressos e devidamente encadernados. Os CDs devem incluir o código JAVA (fonte e bytecode) da aplicação desenvolvida num único ficheiro JAR, e todos os ficheiros HTML gerados pelo JavaDoc. Os CD s e devem ser devidamente acondicionados e identificados com o nome dos alunos, da turma e do docente de Laboratório. Todo o conjunto deverá ser entregue selado dentro de um envelope, correctamente identificado, com os elementos do grupo e do docente a que se destina. Caso, contrário os projectos serão penalizados. A data limite de entrega do projecto é a semana 3/1/2005 a 7/1/2005 nas respectivas aulas laboratoriais. Os projectos não entregues pessoalmente aos docentes, até à data limite, serão cotados com zero valores. 1/5

2 II. Elementos a Apresentar 1. Manual Técnico Organizado com a estrutura definida no ponto IV deste documento. O projecto é assim dividido em duas partes cada uma delas corresponde a uma iteração da Metodologia Unified Process. 1) Iterações na fase de Concepção desenvolvendo-se para essa iteração os workflows de Requisitos, Análise, Desenho e Implementação, com produção dos correspondentes artefactos que farão parte integrante do Manual Técnico 2) Iterações na fase de Elaboração desenvolvendo-se para essa iteração os workflows de Requisitos, Análise, Desenho e Implementação, com produção dos correspondentes artefactos que farão parte integrante do Manual Técnico. É de salientar que a esta iteração deve ser feita tendo como ponto de partida os artefactos produzidos na primeira iteração e considerando os cenários alternativos necessários face à introdução do requisito adicional, especificado em III. 2. Material em CD-ROM Deve conter a aplicação desenvolvida por pacotes (código e bytecode) num único ficheiro JAR (que possa ser executado) e os ficheiros HTML gerados através do JavaDoc. Sem prejuízo da apresentação de artefactos adicionais, que serão valorizados, fazem parte do conjunto mínimo de elementos a apresentar, os seguintes: Diagrama de Casos de Utilização, que permitirão definir o âmbito da iteração que o grupo se propõem desenvolver. Apenas deverão ser objecto de desenvolvimento textual os casos de utilização que façam parte do âmbito da iteração; Diagrama de Classes que reflicta as estrutura global do sistema, com o detalhe das relações, funções e atributos relevantes, para a iteração; Diagrama de Objectos de uma vista particular do sistema, seleccionando, com enfoque nas instâncias das classes relevantes para a iteração; Um dos Diagramas de Interacção ilustrando a colaboração/ interacção entre instâncias de classes relevantes para a iteração definida; Um Diagrama de Estados para a classe Bilhete; Um Diagrama de Actividades ilustrando um algoritmo ou processo de negócio; Durante o desenvolvimento do código deve-se ser tidos em conta os standards de programação definidos no Anexo. Casos de Testes implementados através de classes de teste. Através dos Casos de Testes e das classes correspondentes deve ser possível simular a interacção de um utilizador com o programa e verificar o seu resultado (válido ou inválido). 2/5

3 III. Especificação Informal do Sistema de Informação da gestão de bilhetes de um evento musical internacional A gestão de bilhetes de um evento musical internacional necessita armazenar grandes quantidades de dados. Cada bilhete é adquirido por uma determinada pessoa e será utilizado pela mesma ou outra pessoa. Cada bilhete permite ao utilizador entrar no recinto do evento numa determinada data. Para cada pessoa é necessário guardar a sua nacionalidade, o número do documento de identificação e o tipo desse documento. Para atrair o maior número de participantes a organização disponibiliza três tipos de bilhetes: Bilhete Vip que permite acesso à Tenda VIP (bar e restaurante de acesso restrito aos portadores deste tipo de bilhete), acesso ao parque de estacionamento, etc.; Bilhete Normal; Bilhete Cartão Jovem para os aderentes ao cartão jovem. Por razões de segurança, cada bilhete tem um número único de série e identifica a pessoa que o adquiriu, assim como a pessoa que o vai utilizar. A mesma pessoa não pode utilizar dois bilhetes distintos na mesma data. Cada pessoa apenas pode adquirir, no máximo, seis bilhetes para cada data. Para evitar falsificações, cada bilhete é vendido por uma determinada entidade. Essa entidade tem um número de contribuinte (NIF) e um nome comercial. Cada bilhete contém a identificação da entidade que o vendeu, e existe uma lista das entidades autorizadas para vender bilhetes. De forma a tornar a venda mais flexível, é permitido que uma entidade venda bilhetes em excesso a outra entidade desde que faça parte das entidades autorizadas. Nesse caso, é preciso armazenar a entidade que vendeu e a entidade que comprou o bilhete para revenda. Essa entidade pode, se quiser, vender novamente o bilhete a outra entidade. E assim por diante. Requisito Adicional: É possível reservar bilhetes assim como cancelar a reserva de bilhete. A reserva cancela automaticamente se até 3 dias antes do evento os bilhetes não forem levantados. 3/5

4 IV. Regras para a Elaboração do Manual Capa (deverá conter para além dos elementos standard a versão) Índice i- Índice de capítulos ii- Índice de figuras 1. Introdução 1.1. Organização Descrição sobre a organização do documentos (ex. descrição sumária do conteúdo dos capítulos) 1.2. Objectivo do Documento fim a que se propõe o documento 1.3. Definições, Conceitos e Abreviaturas Utilizadas 2. Apresentação Geral do Sistema (ex.: descrição dos requisitos do Sistema) 3. Modelação de acordo com a estrutura enunciada no capítulo II deste documento. 3.1 Introdução e Considerações Gerais 3.2 1º Versão (1ªIteração) 1) Requisitos 2) Análise 3) Desenho 4) Implementação (Protótipo das Interfaces) º Versão (2ªIteração) 1) Requisitos 2) Análise 3) Desenho 4) Implementação da iteração. 5) Testes O trabalho deverá ser discutido e defendido oralmente podendo aí sofrer ajustes de classificação. As discussões serão feitas individualmente perante dois docentes da disciplina. 4/5

5 ANEXO - Convenções para Codificação em Java Utilizar as seguintes regras na codificação de programas Java, na disciplina de Programação Orientada aos Objectos: 1. Colocar apenas uma instrução por linha. Uma instrução deve-se no entanto estender por várias linhas, de forma que, nenhuma delas contenha mais do 70 caracteres por linha. 2. Nomes de classes devem começar por uma maiúscula. As letras seguintes devem ser minúsculas, excepto no início de novas palavras. Evitar o uso de abreviaturas e acrónimos. Não usar traços de união (underscores). Bons nomes de classes: Funcionario, DetalheDocumento. Maus nomes de classes: viatura, ANIMAL, Editora_Livro. 3. Nomes dos métodos devem ser verbos e iniciar-se por letras minúsculas. Letras subsequentes devem também ser minúsculas, excepto se forem a primeira letra de novas palavras. Não usar traços de união. Bons nomes de métodos: saltar(),saltaralto(), jogar(), chamarpedro(). Maus nomes de métodos: pedro(), Atirar(), atirar_dado(). 4. Nomes de variáveis são geralmente substantivos e devem iniciar-se por letras minúsculas. As letras subsequentes devem também ser minúsculas, excepto se forem a primeira letra de novas palavras. Não usar traços de união. Os nomes das variáveis devem ter significado e não ser nem curtos nem verbosos. Nomes de variáveis com uma letra devem ser evitados, excepto se se tratar de variáveis temporárias. Nomes usuais para variáveis temporárias podem ser: i, j, k, m, n para inteiros e c, d, e para carácteres. Bons nomes de variáveis: polido, roda, meumotor. Maus nomes de variáveis: Joao, minha_altura. 5. Variáveis de instância e de classe (static) podem ou seguir a regra geral dos nomes das variáveis ou serem iniciadas por um traço de união (underscore) seguido de letras minúsculas. Bons nomes: _identificador, _sinal. Maus nomes: _ Identificador, Sinal, tempomaximo. 6. Constantes devem ter nomes constituídos por letras maiúsculas e traços de união. Bons nomes de constantes: NUMERO_RODAS, ALTURA_MAXIMA. 7. Deve-se ser consistente na colocação de chavetas, espaços e na paragrafação. 8. Não utilizar métodos deprecated. 9. Remover código obsoleto e não utilizado. Não basta comentá-lo. Regras de codificação mais pormenorizadas estão disponíveis em: 5/5