Tout d'abord, introduire la pile technologique
l'avant
Nous avons produit le produit est une application Android, tous les pays développés pour la production basé sur Android SDK de Google. Nous utilisons Android Studio développement, le développement du langage Java.
Android Studio sur IntelliJ IDEA, est Android de Google offre aux développeurs des outils de développement sur le marché aujourd'hui est le plus largement utilisé IDE de développement Android. Dans le cadre du développement de logiciels, nous pouvons utiliser l'éditeur de mise en page puissant et pratique, faites glisser l'effet des commandes d'interface utilisateur et d'effectuer un aperçu.
Bien que notre objectif est que tous les utilisateurs des étudiants du Nord, mais aussi prendre en compte un grand nombre d'étudiants du Nord à utiliser le système iOS, mais en raison du nombre et du temps, nous iOS Aucun plan de développement frontal, et nous nous efforçons de livrer le produit fini dans la plate-forme Android le plus tôt possible. Si la version Alpha de la conception a été bien reçu, nous envisagerons le développement d'iOS frontaux.
backend
Backend Django comme cadre, MySQL comme base de données pour obtenir la langue en Python.
Django lui-même est un équilibre entre les extrémités avant et arrière du cadre peut également être en mesure de faire tout le développement de la pile, mais nous utilisons uniquement les fonctions pertinentes de son back-end. modèle de conception MVC Django a une base, la fondation fournit un certain nombre de fonctionnalités pour répondre aux besoins de notre fin avant et après l'interaction. Nous pourrions envisager d'utiliser framework Django REST comme cadre de mise en œuvre back-end, ce qui reflète le développement RESTful.
Base de données
Base de données en utilisant MySQL. base de données MySQL est le plus familier est l'utilisation d'un grand nombre de bases de données, plus stable, et la technologie connexe est plus mature, et la phase de Django est également très bon.
Django est livré avec la base de données SQLite plus portable, peut être utilisé comme l'utilisation de débogage local, mais pas pour le déploiement de plus de personnes utilisent l'offre sur le serveur, les performances peuvent être limitées.
reptile
À l'heure actuelle, pour des raisons de sécurité, l'école n'a pas l'interface directement à la base de données à lire ouvert aux étudiants, nous ne pouvons pas obtenir les données sur les sites éducatifs de façon classique. Mais nous voulons encore faire de ce logiciel, il est forcé de choisir un reptile pour obtenir les données
Comme la session de vérification du Sénat du Nord est plus complexe, et les systèmes éducatifs ont des iframestructures plus complexes et autres, il est difficile d'utiliser un cadre général pour les reptiles, donc nous avons choisi un outil facile à utiliser un Sélénium navigateur sans tête comme un outil pour obtenir des données de l' école.
Nous allons contrôler la fréquence d'exploration et de données, seront garanties de ne pas effectuer des opérations transfrontalières pour protéger la sécurité de l'utilisateur dans une large mesure.
En même temps, le stockage de données statique de base de données en utilisant le cryptage, clé de déchiffrement est généré par l'utilisateur, repose dans les mains des utilisateurs, ce qui permet aux développeurs qui ne peuvent pas se rendre à compte d'authentification unifiée de tout le monde par un moyen simple d'interroger la base de données.
environnement cloud
Nous en utilisant bien sûr mis provisoirement des ressources cloud Huawei fournies pour 1 noyau 1G serveur.
Compte tenu de la situation actuelle, un 1G nucléaire aussi, peut ne pas être en mesure de répondre à nos besoins, lorsque des fréquences plus élevées reptiles crawling, pourrait conduire à une mémoire insuffisante et la plus importante bande passante du serveur plus ou moins aura une incidence sur notre réponse vitesse. Si elle est jugée insuffisante dans la pratique, il peut considérer leurs propres frais pour remplacer les configurations de serveur plus.
En second lieu, les extrémités avant et arrière Interface design
Extrémités avant et arrière bout à bout en utilisant le protocole HTTPS demande à remplir. En même temps, nous suivons les principes RESTful des idées de conception, il suffit d'appeler les interfaces front-end pour obtenir des données, vous n'avez pas besoin de penser détails à l'intérieur. Design Architecture est montré:
Ce qui suit est une des règles d'interface provisoires, être affinées.
| # | méthode de requête | chemin de demande | utilisation |
|---|---|---|---|
| 1 | POST |
/api/users/phone_num/verify/code |
Envoyer le code de vérification de téléphone |
| 2 | POST |
/api/users/phone_num/verify |
Le code de vérification est correcte |
| 3 | POST |
/api/users/email/verify |
Vérifiez boîte aux lettres, envoyer une lettre à la boîte aux lettres |
| 4 | GET |
/api/users/email/verify/:uid/:hash_code |
email de vérification, cliquez sur le lien vers la boîte aux lettres de retour |
| 5 | POST |
/api/users/forgetpassword/email |
Vous avez oublié votre mot de passe, lié courrier |
| 6 | GET |
/api/users/forgetpassword/email/verify/:uid/:hash_code |
Vous avez oublié votre mot de passe, email saute |
| sept | POST |
/api/users/forgetpassword/phone_num/send |
Vous avez oublié votre mot de passe, téléphone |
| 8 | POST |
/api/users/forgetpassword/phone_num/verify |
Vous avez oublié votre mot de passe, vérification par téléphone |
| 9 | GET |
/api/users/:uid/get_class |
Obtient calendrier |
| dix | GET |
/api/users/:uid/update_class |
Calendrier Mise à jour |
| 11 | GET |
/api/users/:uid/todolist |
La requête de cours Centre |
| 12 | GET |
/api/empty_room |
Vide enquête en classe |
| 13 | GET |
/api/users/:uid/get_score |
résultats de la requête |
Troisièmement, les principes de conception
-
abstrait
-
comportement Résumé
acte abstrait principalement sur le front-end interactif et back-end, back-end et les reptiles. Nous sommes l'interface pour des fonctions spécifiques ont été clairement définies, dans lequel l'appelant n'a pas besoin d'opération spécifique à craindre.
-
Abstraction données
Nous présenterons toutes les données dans la base de données, la conception de base de données dans models.py, chaque emballé dans une table cible, lecture et les opérations d'écriture pour faciliter les ajouts et les suppressions. Bien que les changements dans la structure des dossiers de maintenance pour la migration, de faciliter le développement et l'entretien futur.
-
-
Cohésion / couplage / modulaire
Principalement sur la conception arrière-plan. framework Django lui-même utilisé pour supporter l'extrémité arrière du modèle MVC est plus pratique, chacune des caractéristiques différentes peuvent être conçus en différentes djangoapp, chaque méthode a sa propre gestion de djangoapp, n'affectent pas les uns des autres dans les données et les fonctions entre elles.
L'APP avant également divisé en différentes pages, chaque page a sa propre fonction indépendante, ils n'affectent pas, chaque page de leurs fonctions, pour compléter leur propre fonction, qui est le développement inévitable de la division.
-
Séparation des informations cache et l'encapsulation, les interfaces et la mise en œuvre
informations d'encapsulation cachés, une architecture de séparation de principe sont des extrémités avant et arrière. Nous ne l'avons pas mis toutes les requêtes dans le programme utilisateur pour atteindre, mais les utilisateurs expérimentés - Serveurs - processus éducatif, d'interagir avec aussi peu d'informations à cacher entre, seulement à travers les échanges d'API avec l'autre sans exposer les détails internes.
La distale de la main de l'utilisateur Android APP, elle-même a une bonne encapsulation, et la lecture de données illégales déballer avec une certaine difficulté, et a un bon paquet à l'information aide cacher, l'interface et la séparation de mise en œuvre.
-
Comment gérer les conditions d'erreur
En tant que Android APP, l'avant gauche à l'utilisateur la possibilité de faire des erreurs est très limitée, si des erreurs simples comme entrée illégale se produit, il sera détecté à l'avant, il ne transmet pas la demande au back-end.
La plupart des erreurs seront détectées dans l'arrière-plan. Une fois que les erreurs sont détectées, ou l'extrémité arrière de l'erreur rampants crawler interne se produit, renvoie le code d'état HTTP correspondant, pour déterminer quel type d'erreur est survenu. L'extrémité avant du Code traduit en texte qui indique à l'utilisateur quelle erreur spécifique est apparu que les utilisateurs give instructions détaillées d'exploitation.
-
Modèles pour l'environnement d'exploitation, des modèles connexes, paramètres d'entrée et de sortie ont une hypothèse? Ces hypothèses et du personnel associé a vérifié?
Utilisation de l'environnement et la plate-forme Android frontal basé sur un modèle, qui a lui-même un grand nombre d'applications disponibles pour référence, et nos produits ne sont pas les performances et les exigences du réseau, il n'y aura pas beaucoup d'un problème.
Back-end il peut y avoir quelques problèmes pour les reptiles de traitement de haute concurrence, la consommation principalement des ressources du serveur est trop grand, ce qui entraîne des performances ne peut pas suivre, si des questions se posent la pratique ultérieure, nous allons remplacer immédiatement l'environnement cloud.
Avant et interaction latérale arrière demande HTTPS à charge, paramètres d'entrée et de sortie lui-même a des normes très strictes limites, et nous avons une bonne conception de gestion des erreurs, il ne sera pas un gros problème dans l'interaction.
-
Flexibilité pour faire face au changement
La flexibilité est construit sur un couplage modulaire et faible. Nous essayons de séparer l'extrémité avant et arrière, modulaire arrière-plan possible est également sur cette base. Si de nouveaux besoins apparaissent, ou des sites éducatifs des circonstances imprévues, nous pouvons modifier aussi peu que possible dans le code, l'achèvement de notre travail, afin de refléter un degré élevé de flexibilité.
-
De grandes quantités de capacités de traitement de données
Pour la puissance de traitement back-end d'un grand nombre de demandes de l'avant, construite sur les performances du framework Django de la rationalité et le serveur lui-même, les deux qui ont été vérifiées dans d'autres grands projets. Dans la conception de l'interface, nous avons autant que possible a été simplifié le contenu de l'API et les données car l'interface ne traite pas des problèmes causés par la difficulté de se qualifier.
Pour un grand nombre de reptiles commande du traitement back-end peut être une difficulté. Le serveur lui-même ne supporte pas la bande passante et des ressources pour ouvrir des requêtes simultanées haut chrome, de sorte que notre solution est de réduire le nombre de ramper. Peut être résolu par le mécanisme de mise en cache pour déterminer les données dans un court laps de temps ne changera pas, nous ne crawling répétition, dans la mesure du possible de réduire la pression sur le serveur.