AlarMed

Fase 2

Escopo

• Aplicativo que permite ajudar idosos e pessoas com dificuldades de memória ou leitura a seguirem seus tratamentos medicamentosos de forma mais segura e independente, promovendo a saúde e bem-estar. Ele envia lembretes personalizados diretamente para o celular, ajudando a evitar esquecimentos ou confusões com horários e doses, que são alguns dos principais obstáculos na adesão ao tratamento;
• Além disso, pensando na acessibilidade, o app permite o cadastro imagens das embalagens dos remédios, facilitando a identificação visual. A gestão de estoque é também uma função muito importante, pois alerta o usuário — seja o idoso ou o cuidador — quando é hora de repor os medicamentos, ajudando a evitar interrupções no tratamento.
• Em essência, o aplicativo AlarMed tem o objetivo de devolver autonomia ao idoso na hora de cuidar da sua medicação, oferecendo suporte contínuo tanto para ele quanto para os cuidadores e familiares. Assim, garante que o tratamento seja feito de forma correta e completa.

Requisitos Funcionais

Fase 1 - 2025-1

• RF-01: Cadastrar medicamentos
  • O sistema deve permitir o cadastro de medicamentos com informações como nome, dosagem, frequência, horário e observações.

• RF-02: Cadastrar usuários
  • O sistema deve permitir o cadastro de usuários (idosos e cuidadores) com informações como nome, e-mail e telefone.

• RF-03: Editar informações de cadastro
  • O sistema deve permitir a edição de informações sobre os usuários cadastrados e dos medicamentos registrados.

• RF-04: Editar ou remover medicamentos
  • O sistema deve permitir ao usuário editar ou excluir medicamentos já cadastrados.

• RF-05: Emitir lembretes
  • O sistema deve emitir lembretes nos horários definidos para lembrar o usuário de tomar as medicações.

• RF-06: Gerenciar estoque de medicamentos
  • O sistema deve registrar a quantidade inicial dos medicamentos e atualizá-la automaticamente com base no uso diário.

• RF-07: Visualizar histórico
  • Permitir o acesso ao histórico de medicamentos tomados e datas de reposição.

Fase 2 - 2025-2

• RF01: Criar perfil de acesso
  • O sistema vai implementar um mecanismo de criação de perfis de acesso, permitindo diferentes tipos de usuários, como Idoso e Cuidador, além do perfil Administrador. Cada perfil terá níveis de permissão específicos, controlando as funcionalidades que podem ser acessadas ou modificadas.

• RF02: Editar configurações do aplicativo
  • O sistema permitirá que usuários com perfil Administrador editem configurações tanto do próprio aplicativo quanto dos usuários vinculados (Idoso e Cuidador). Isso inclui alterar dados pessoais, permissões, preferências de uso, configurações de lembretes e opções de acessibilidade, garantindo que o app se adapte às necessidades de cada perfil.

Requisitos Não-funcionais

Fase 1 - 2025-1

• RNF-01: Interface Intuitiva
  • O sistema deve possuir uma interface intuitiva e simplificada, adequada para usuários idosos com baixa familiaridade tecnológica. A navegação deve ser linear e previsível, com fluxos claros que diminuam a possibilidade de confusão. O aplicativo deve utilizar terminologia simples e familiar, evitando jargões técnicos. Mensagens de confirmação e feedback devem ser claras e imediatas, garantindo que o usuário sempre saiba o resultado de suas ações.

• RNF-02: Acessibilidade Visual
  • O sistema deve possuir botões grandes, com contraste alto entre texto e fundo, fonte grande e legível, ícones e símbolos de fácil reconhecimento associados aos botões, isso garante que os idosos possam navegar e interagir com o aplicativo de forma eficaz.

• RNF-03: Autonomia Completa
  • O aplicativo deve funcionar 100% sem conexão com internet, WiFi ou dados móveis. Todas as funcionalidades devem operar de forma independente, sem nenhuma dependência de serviços online ou APIs externas. A disponibilidade de notificações e alarmes deve ser totalmente independente de conectividade, garantindo que os lembretes funcionem sempre, mesmo sem internet.

• RNF-04: Armazenamento Local
  • O aplicativo deve armazenar todos os dados exclusivamente no dispositivo utilizando SQLite. O backup automático local dos dados deve ser realizado no próprio dispositivo, permitindo a recuperação completa das informações em caso de falha.

• RNF-05: Compatibilidade de Dispositivos
  • O app deve ser compatível com diferentes dispositivos, sendo alguns deles: Android, IOS e suporte a tablets e smartphones.

• RNF-06: Segurança e Privacidade de Dados
  • O sistema deve manter todos os dados armazenados exclusivamente no dispositivo local, com zero transmissão de dados pela internet em qualquer circunstância. Deve implementar criptografia para proteger dados sensíveis no SQLite, garantindo a segurança das informações médicas. Não deve haver coleta de dados de uso, telemetria ou qualquer rastreamento do usuário. Devem ser apresentados termos de uso e política de privacidade em linguagem clara, adequada ao público idoso, com consentimento explícito respeitando integralmente os princípios da LGPD.

• RNF-07: Modularidade
  • O sistema deve ser construído sobre uma arquitetura modular, onde os componentes são independentes, facilitando a manutenção, a escalabilidade e a adição de novas funcionalidades com baixo impacto sobre os componentes existentes.

• RNF-08: Sistema de Alarmes
  • Deve funcionar independentemente do estado do aplicativo, ter múltiplos tipos de notificação (visual, sonora, vibração) e repetição automática até confirmação do usuário.

• RNF-09: Capacidade de Dados
  • O sistema deve ter suporte para o armazenamento e gerenciamento de pelo menos 50 medicamentos simultâneos.

• RNF-10: Capacidade de Dados
  • O sistema deve manter uma performance estável e um tempo de resposta aceitável mesmo com o crescimento dos dados e a complexidade das interações, assegurando uma experiência de usuário fluida.

• RNF-11: Recuperação de Falhas
  • O sistema deve implementar mecanismos de validação de dados de entrada para prevenir inconsistências e erros, como horários e dosagens incorretas, assegurando a confiabilidade e a integridade das informações do tratamento.

Fase 2 - 2025-2

• RNF01: Usabilidade
  • O sistema será aprimorado para proporcionar uma experiência mais simples, clara e intuitiva para usuários idosos, reduzindo a carga cognitiva durante a interação. Para isso, serão adotados elementos como textos ampliados, ícones de fácil reconhecimento, mensagens objetivas e feedback imediato. O objetivo é garantir que pessoas com pouca familiaridade tecnológica consigam utilizar o aplicativo com autonomia e segurança.

• RNF02: Interface e Design
  • O sistema passará por melhorias visuais com foco em acessibilidade e conforto visual. Serão realizados ajustes no layout, aumento de contraste, reorganização dos botões, uso de cores mais agradáveis e padronização da identidade visual. Essas alterações visam tornar a interface mais moderna, legível e visualmente amigável, garantindo uma experiência mais agradável e funcional.

Melhores práticas

1. Responsabilidade Única (SRP) – Classe AlarmReceiver

Por que é uma boa prática

Mantém a classe focada em uma única função, facilitando entender o que ela faz. Deixa a manutenção mais simples, pois mudanças afetam apenas essa parte. Ajuda nos testes, permitindo validar o comportamento isoladamente. Reduz acoplamento ao delegar tarefas para classes mais específicas.

Trecho de código app/src/main/java/com/example/alarmed/alarm/AlarmReceiver.java (linhas 9–32)

 public class AlarmReceiver extends BroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {

        int medicamentoId = intent.getIntExtra("MEDICAMENTO_ID", -1);
        String medicamentoNome = intent.getStringExtra("MEDICAMENTO_NOME");

        if (medicamentoId != -1 && medicamentoNome != null) {

            NotificationHelper helper = new NotificationHelper(context);
            helper.showNotification(context, medicamentoId, medicamentoNome);

        } else {
            Log.w("AlarmReceiver",
                "Dados inválidos - ID: " + medicamentoId + ", Nome: " + medicamentoNome);
        }
    }
}

2. Interface Segregation Principle (ISP) – DAOs Separados

Por que isso é uma boa prática

Cada DAO tem apenas os métodos relacionados à sua própria entidade. Evita interfaces “gigantes” e difíceis de manter. Reduz acoplamento. Facilita testes e organização.

Trecho de código app/src/main/java/com/example/alarmed/data/db/daos/MedicamentoDao.java (linhas 17–60)

@Dao
public interface MedicamentoDao {

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    long save(Medicamento medicamento);

    @Update
    void update(Medicamento medicamento);

    @Query("SELECT * FROM medicamento ORDER BY nome ASC")
    LiveData<List<Medicamento>> getAllMedicamentos();

    @Transaction
    @Query("SELECT * FROM medicamento")
    LiveData<List<MedicamentoComHorarios>> getAllMedicamentosComHorarios();
}

3. Nomenclatura Padronizada

Por que é uma boa prática

Deixa o código mais fácil de ler para qualquer desenvolvedor. Mantém consistência em todo o projeto. Evita confusões entre nomes de métodos e variáveis. Segue os padrões oficiais do Java.

Métodos usando camelCase

Exemplo 1: MedicamentoViewModel.java (linhas 17–29)

 public class MedicamentoViewModel extends AndroidViewModel {

    private final MedicamentoRepository mRepository;
    private final LiveData<List<Medicamento>> mAllMedicamentos;

    public MedicamentoViewModel(@NonNull Application application) {
        super(application);
        mRepository = new MedicamentoRepository(application);
        mAllMedicamentos = mRepository.getAllMedicamentos();
    }

    public LiveData<List<Medicamento>> getAllMedicamentos() {
        return mAllMedicamentos;
    }
}

Constantes usando UPPER_SNAKE_CASE

public static final String REMINDER_CHANNEL_ID = "reminder_channel";
public static final String LOW_STOCK_CHANNEL_NAME = "Alertas de Estoque";

Campos de banco usando snake_case

 @ColumnInfo(name = "horario_inicial")
public String horario_inicial;

4. Tratamento de Erros e Validações

Por que é uma boa prática

Evita que o app trave em situações inesperadas. Impede que o sistema continue com dados errados. Facilita identificar o problema por meio dos logs. Garante que permissões e regras do Android sejam respeitadas. Usa retorno antecipado (early return) quando necessário.

Validação de dados recebidos

 if (medicamentoId != -1 && medicamentoNome != null) {

    NotificationHelper helper = new NotificationHelper(context);
    helper.showNotification(context, medicamentoId, medicamentoNome);

} else {
    Log.w("AlarmReceiver",
        "Dados inválidos - ID: " + medicamentoId + ", Nome: " + medicamentoNome);
}

Tratamento de erros e try/catch

 if (horario == null ||
    horario.horario_inicial == null ||
    horario.horario_inicial.isEmpty()) {

    Log.e("AlarmScheduler", "Horário inválido");
    return -1;
}

try {

    String[] parts = horario.horario_inicial.split(":");
    int startHour = Integer.parseInt(parts[0]);
    int startMinute = Integer.parseInt(parts[1]);

} catch (Exception e) {
    Log.e("AlarmScheduler", "Erro ao calcular próximo horário", e);
    return -1;
}

Verificação de permissões

 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S &&
        !alarmManager.canScheduleExactAlarms()) {

    Toast.makeText(
            context,
            "Permissão para alarmes exatos não concedida.",
            Toast.LENGTH_LONG
    ).show();

    return;
}

5. Constantes Centralizadas

Por que é uma boa prática

Evita “magic strings” espalhadas no código. Centraliza tudo em um só lugar. Mantém consistência entre arquivos. Reduz erros por digitação incorreta.

Trecho de código

 public class NotificationHelper extends ContextWrapper {

    private static final String CHANNEL_ID = "alarm_channel";

    public static final String REMINDER_CHANNEL_ID = "reminder_channel";
    public static final String REMINDER_CHANNEL_NAME = "Lembretes de Medicação";

    public static final String LOW_STOCK_CHANNEL_ID = "low_stock_channel";
    public static final String LOW_STOCK_CHANNEL_NAME = "Alertas de Estoque";

    private static final int LOW_STOCK_NOTIFICATION_ID_OFFSET = 10000;
}

CRONOGRAMA

Item	Data	Atividades Alarmed	Realizado
1	14/11/2025	Definir Proposta de Projeto	100%
2	14/11/2025	Validar Visão do Usuário	100%
3	14/11/2025	Especificar RFs e RNFs - Fase 2	100%
4	17/11/2025	RF01: Desenvolver perfil de acesso	100%
x	24/11/2025	TeckWeek
5	01/12/2025	Melhores Práticas	100%
6	01/12/2025	Incrementar diferencial tecnológico	100%
7	01/12/2025	RF01: Desenvolver perfil de acesso	100%
8	01/12/2025	RF01: Desenvolver perfil de acesso	100%
9	08/12/2025	RF 02: Editar configurações do aplicativo	100%
10	15/12/2025	2a entrega - Vídeo até 19/12 pelo Teams - RFs 1 e 2	100%
11	19/12/2025	Vídeo encaminhado para cliente	Aguardando avaliação

Item	Data	Atividades Alarmed	Responsável
1	23/02/2026	Entrega de 10 itens do documento (5% feito)	Isabella Simão
2	23/02/2026	Entrega do front-end atualizado (tela de login)	Jaqueline
3	23/02/2026	Entrega do front-end atualizado (tela de histórico)	Layza
4	23/02/2026	Entrega de 10 itens do documento	Amanda Júlia
5	23/02/2026	Entrega de 10 itens do documento	Paula
6	23/02/2026	Entrega de 10 itens do documento	Izabela
7	02/03/2026	Entrega de 10 itens do documento	Isabella Simão
8	02/03/2026	Entrega de 10 itens do documento	Amanda Júlia
9	02/03/2026	Entrega de 10 itens do documento	Paula
10	02/03/2026	Entrega de 10 itens do documento	Izabela
10	02/03/2026	Entrega do front-end atualizado (tela de cadastro)	Jaqueline
10	02/03/2026	Entrega do front-end atualizado (tela de visualização inicial - medicamentos)	Layza
11	09/03/2026	Entrega de 10 itens do documento	Isabella Simão
12	09/03/2026	Entrega de 10 itens do documento	Amanda Júlia
13	09/03/2026	Entrega de 10 itens do documento	Paula
14	09/03/2026	Entrega de 10 itens do documento	Izabela
15	16/03/2026	Apresentação do aplicativo	Grupo