Trabalho prático 2004/2005

Paulo Sousa
Novembro 2004
[ voltar à página de ADAV ]

Estes são apenas alguns comentários que devem ser levados em linha de conta na análise autocrítica do trabalho que devem efectuar, mas que não identificam na totalidade os erros e deficiências dos trabalhos. Com base nestes comentários/indicações e na avaliação efectuada de cada trabalho, devem efectuar uma análise autocrítica à vossa solução antes de avançar para a implementação da fase 2. 

Comentários Gerais

• podem começar por reler o enunciado, as regras de avaliação e as regras de conteúdo do relatório. também se aconselha que releiam o guião de Introdução ao Desenvolvimento de Aplicações baseadas em Componentes para relembrar conceitos base (pg. 27-28):
   
  • Componente - um componente é uma unidade de distribuição em formato binário de código, que fornece serviços através de um contrato bem definido (i.e., uma interface).
     
  • Interface - uma interface é um conjunto coerente de métodos. Por conjunto coerente entenda-se métodos relacionados com um mesmo serviço e/ou trabalhando com entidades de um mesmo domínio.
     
  • Cliente - Um componente é utilizado por terceiros aos quais se dá o nome de “cliente”, um cliente é uma aplicação ou outro componente que faz uso dos serviços de um componente.
     
• em cada método era necessário colocar a descrição do método, dos parâmetros e valor de retorno
   
• em cada método deveriam ter colocado pre- e pos- condições dos métodos (slides aula 6 teórica)
   
• em cada método deveriam indicar que tipo de utilizador é que o pode utilizar (é um exemplo de pré-condição)
   
• deveriam ter explicado o modelo de dados
   
• respeitar regras de nomenclatura básicas

Comentários específicos

• do enunciado ressalta que os principais conceitos de negócio são:
  • Serviço (conceito abstracto de algo que pode ser feito na oficina)
  • plano de revisão,
  • ordem de serviço (realização/concretização de serviços),
  • marcação (i.e, ordem de escalonamento),
  • viatura registada (com matricula),
  • cliente,
  • recepcionista e
  • mecânico.
• Adicionalmente existem os conceitos de:
  • Marca-Modelo (viatura abstracta) para dar suporte aos planos de revisão, 
  • Utilizador (pode estar fundido com mecânico e recepcionista)
  • Factura
  • Intervenção (registo histórico de ordem de serviço efectuada numa viatura)
     
• os métodos devem estar relacionados com a interface/entidade de negócio.
  • exemplo negativo: ICliente.FindViaturaByMatricula() -- este método deveria estar em IViatura.
  • exemplo negativo: IViatura.FindByName() -- uma viatura não tem "nome".
  • exemplo positivo. IViatura.GetViaturasByClienteId()
  • exemplo positivo. IViatura.GetOwnerByMatricula()
     
• nesta fase do trabalho apenas interessam as interfaces públicas do componente. detalhes de implementação do componente não são necessários. ao especificarem a interface pública do componente devem verificar se responde aos requisitos de negócio (i.e., implementam as operações de negócio)
   
• em muitos métodos (operações de negócio) é conveniente distinguir entre os diferentes resultados dessa operação. deveriam definir um enumerado para tal (ex: OficinaStatusEnum)
   
• é necessário distinguir o tipo de utilizador que fez login. o método de login deveria retornar indicação do tipo de utilizador ou o registo completo do utilizador, ex: TipoUtilizadorEnum ValidaLogin() ou DataSet ValidateAndGetUtilizador()
   
• um dos princípios base da programação por componentes é a separação de responsabilidades. um caso concreto: a separação da lógica de interacção com o utilizador da lógica de processamento. nesse sentido os métodos do componente necessitam receber todos os parâmetros para que possam efectuar o seu processamento. o valor desses parâmetros é passado pela aplicação cliente (podem ter sido introduzidos pelo utilizador numa janela ou lidos de um ficheiro). portanto métodos tipo ICliente.Add() que não recebem nenhum parâmetro não servem para nada
   
• métodos que criem novas entidades na BD não devem receber como parâmetro o id da entidade a criar, ex., AddViatura(int idviatura, ...). podem no entanto receber valores para campos chave de identificação externa dessa entidade, ex., AddViatura(string matricula, ...).
   
• "listar" não é um bom prefixo para um método que retorna "coisas". Deveriam usar "Get". ex., ICliente.Listar() --> ICliente.GetAll()
   
• "Serviço" é um conceito abstracto. não faz sentido na interface IServico ter um método GetAllByCustomer() ou GetAllByViatura(). esses métodos devem existir na interface IOrdemServico ou IIntervenção - realização concreta do conceito abstracto "serviço"
   
• uma ordem de serviço, uma factura, um plano de revisão é uma entidade composta (ex., possui linhas de detalhe) mas única. na maioria dos casos o "todo" deve ser tratado como uma única entidade. não faz sentido existir um método AddFactura() e outro AddLinhaFactura(). da mesma forma não faz sentido existir um método GetCabFactura() e outro GetLinhasFactura()
   
• também se aplica a obter plano de revisão, deveria ser uma única operação IRevisao.GetPlano() ou IViatura.GetPlanoRevisao(). não faz sentido existir um método IRevisao.GetIdRevisao() e outro IServico.GetAllByRevisaoId(). neste caso faz ainda menos sentido porque os métodos estão em interfaces diferentes.
   
• Embora IFactura.Add() seja aceitável, era mais correcto um método IOrdemServico.Facturar(). o que se pretende não é adicionar uma factura mas sim gerar uma factura para uma ordem de serviço efectuada. há que prestar atenção às operações de negócio; só devem pensar nas entidades em termos CRUD (Create, Update, Read, Delete) quando são operações simples (ex. adicionar um funcionário)
   
• Escalonamento (diferido e imediato). deveria existir um método GetAvailableDay() ou GetScheduleForDay() para obter disponibilidades e outro método Schedule() para efectuar a marcação/escalonamento.
   
• na ordem de serviço deviam guardar a indicação da quilometragem da viatura quando entrou na oficina, observações do cliente (instruções adicionais) e observações dos mecânicos (chamadas de atenção ao cliente sobre situações que ele deve verificar nas próximas visitas). deveria haver um estado para a ordem de serviço (ex., criada, espera_mecanico, concluída, ...) bem como um estado para cada serviço requisitado da ordem. a cada serviço requisitado numa ordem deveria ser possível incluir observações e necessitava de algumas flags de controlo (realizado ou não, a facturar ou não, ...)
   
• de notar que embora as marcações possam passar a ordens de serviço de forma imediata no início do dia de trabalho, faz mais sentido as marcações apenas passarem a ordem de serviço quando o cliente entregou a chave do carro ao recepcionista (só nessa altura é que se torna carga de trabalho efectiva, até lá era apenas previsão)
   
• o plano de revisão de uma viatura é uma simples template da ordem de serviço. quando o cliente marca uma visita à oficina com base numa revisão pré-definida, devem copiar o plano de revisão para uma ordem de serviço; o cliente pode pedir outros serviços ou indicar que não deseja efectuar determinado serviço da revisão (por ex., já tinha mudado o óleo na semana passada). após esta interacção entre recepcionista e cliente é que é gerada a ordem de serviço ou escalonamento.
   
• numa oficina automóvel "viatura" é um conceito de negócio mais importante que "cliente", e tendo em conta a relação entre os dois conceitos era aceitável o agrupamento numa única interface IVeiculo com métodos Add(), UpdateOwnerData(), FindByMatricula(), FindByOwnerName(), ...
   
• há conceitos que não podem ser apagados!. ex., Serviço. quando muito pode deixar de fazer parte dos serviços prestados e passa a "inactivo". tem que continuar a existir por motivos históricos.
   
• Uma factura não pode ser apagada nem alterado depois de ser criada!!!
   
• atenção aos tipos de dados utilizados. usar strings para parâmetros "preco" ou long para "numero telefone" não faz muito sentido
   
• utilização de DataSets como parâmetro de entrada nos métodos, ex., AddViatura(DataSet v), necessita de mecanismos para garantir que o DataSets tem a estrutura pretendida. deveriam utilizar TypedDataSets ou existir um método CreateEmptyXXX() que devolveria um DataSets devidamente estruturado. tal como é feito no trabalho de referência na interface ISale.
   
• utilização de estruturas/classes prédefinidas para representar as entidades de negócio deve ser coerente. não faz sentido uns métodos utilizarem essa estrutura e outros não. ex. IViatura.Add(DadosViatura v) e DataSet IViatura.GetAll(). o que faria sentido era o segundo método retornar um array de DadosViatura.
  • NOTA: este modelo de desenvolvimento implica um maior trabalho de implementação já que necessitam transformar os DataSets nas vossas estruturas próprias
     
• conjunto mínimo de serviços decorrentes da leitura do enunciado:

Interfaces	tópico	comentário
ICustomer.Add	1	adicionar e alterar dados de cliente
ICustomer.Update
ICustomer.AddViatura	2	adicionar e alterar dados de uma viatura. eventualmente pode adicionar em simultâneo um novo cliente
IViatura.Add
IViatura.Update
IViatura.SetCustomer
ICustomer.GetViaturas	3	obter informação sobre as viaturas de um cliente
IViatura.GetByCustomer
IMarcacao.Schedule	5	efectuar uma marcação ad hoc ou a partir de um plano de revisão. pode existir um outro método para gerar uma ordem de serviço (em memória - DataSet) com base num plano de revisão que possa ser alterada pelo utilizador. deve validar se a marcação é possível
IMarcacao.Schedule	5
IOrdemServiço.Create	5	criar uma ordem de serviço imediata (deve fazer a mesma validação utilizada no método para escalonamento)
IServiço.UpdatePrice	6	alterar o preço de um serviço (ex., mudança de óleo motores a gasolina passa a custar 15€)
IMarcacao.GetScheduledByDay	7	obter informação sobre as marcações e/ou ordens de serviço de um determinado dia e informação sobre ocupação de cada mecânico para saber disponibilidades
IOrdemServiço.GetAssigned	8	obter informação sobre as ordens de serviço a executar. pode trazer informação especifica para cada mecânico caso optem por atribuir directamente a execução de uma ordem a um mecânico, ou então traz informação sobre as ordens livres e cada mecânico executa a 1ª ordem que encontrar
IOrdemServiço.GetNotStarted
IOrdemServiço.Finish	9	finaliza uma ordem de serviço. internamente vai utilizar o componente para envio de SMS ao cliente
ICustomer.GetIntervenções	4a	obter histórico de intervenções (datas, serviços efectuados, custo, ...) de um cliente.
IIntervencao.GetByCustomer
IViatura.GetIntervencoes	4b	obter histórico de intervenções (datas, serviços efectuados, custo, ...) de uma viatura.
IIntervencao.GetByViatura
IUser.Login	a	valida o utilizador no sistema
IMarcacao.ConvertToOrdemServiço	b	com base nas marcação existentes, transformar uma marcação em ordem de serviço quando o cliente entrega o carro na oficina (ou eventualmente no inicio do dia).
IMarcacao.Cancel	c	cancelar uma marcação (ex., o cliente não apareceu)
IOrdemServiço.Update	d	alterar uma ordem de serviço acrescentando novos serviços (após falar com cliente), remover serviços desnecessários, alterar estado da ordem, acrescentar observações, etc..
IOrdemServiço.AddServico
IOrdemServiço.RemoveServico
IOrdemServiço.UpdateStatus
IOrdemServiço.SetObservacoes
IOrdemServiço.AssignMecanico	e	atribuir um mecânico a uma ordem (pode ser atribuição automática aquando da criação da ordem ou então ocorre quando o mecânico pega na ordem livre e inicia o trabalho)
IOrdemServiço.Facturar	f	gerar uma factura com base no trabalho executado na ordem. pode também permitir gerar documento word com factura e observações incluídas na ordem de serviço.

[ Home Page | Fabricare | Publicações | Bookmarks | Disciplinas | Download ]

comentários e sugestões

Última Alteração: 17 de Novembro de 2004