Qual è il nome della parte dell'applicazione, che gestisce le persone in generale? [chiuso]

Question

Qual è il nome della parte dell'applicazione, che gestisce le persone in generale? [chiuso]

#1 da (5 voti)
#2 da (1 voti)

0

In ogni applicazione ci sono concetti come utenti, clienti, ecc. e parte dell'applicazione tenta di gestirli. Ad esempio:

1. keeping the information of people, organizations, firms, etc.
2. managing users (people who work with the system)
3. managing customers (people who purchase goods/services)
4. distinguishing customers, from users, from ordinary people, etc.
5. ...

Abbiamo un termine universale per quell'area di ogni applicazione (quel sottosistema, quel modulo, che qualunque cosa)? O se voglio chiedere più precisamente, possiamo confezionare clienti, utenti, persone, organizzazioni, ecc. In un unico modulo e nominarlo come X? Questa è una tassonomia corretta dei sottosistemi?

Aggiornamento: Entità un buon nome?

terminology

posta Saeed Neamati 29.07.2013 - 08:36

fonte

2 risposte

Leggi altre domande sui tag terminology

Monitoraggio degli errori scientifici quando si lavora con numeri a virgola mobile Per un'applicazione web, dovrei creare a livello di codice le tabelle del database o fornire un file di schema e istruzioni?

score 5 · Answer 1

Questa situazione è tipica per le persone che non conoscono i sistemi di costruzione. La chiave qui riguarda i livelli di astrazione che non sono ancora completi nel tuo progetto.

Qualche tassonomia tipica sarebbe ...

Contacts - chiunque sia a conoscenza del sistema.

Users - Contatti che hanno bisogno di accedere al sistema in qualche modo.

A sua volta, anche Users potrebbe essere

Customers che hai acquistato in passato.
Staff che lavora nel business.
Suppliers da chi acquisti.

Fondamentalmente ti riferisci a loro al livello di astrazione che è importante per te in quella fase della tua azione o pianificazione. Ad esempio, non c'è nulla che impedisca a un utente di un membro dello staff e di un cliente.

score 1 · Answer 2

Uno dei prodotti della mia azienda è un'applicazione web destinata a gestire la comunicazione tra agenti e i loro clienti per una società che non vende direttamente al compratore finale ma piuttosto vende agli agenti.

Sia gli agenti che i client devono essere associati a un account utente in questo sistema, ma gli agenti hanno il potere di gestire i client in qualsiasi modo piaccia, poiché appartengono a quel particolare agente. Il modo in cui gestiamo l'autorizzazione non è stabilendo cosa possono fare agenti e client, ma piuttosto assegnando ruoli agli utenti. Il ruolo di un utente è la sua essenza di autorizzazione senza necessariamente essere associato a un particolare utente. Quando l'agente aggiunge un nuovo utente, quell'utente ha automaticamente il ruolo del client, poiché il modo in cui è configurato, l'utente di un particolare ruolo può creare nuovi utenti di un ruolo inferiore e ruoli del client, non avendo alcun ruolo inferiore ad esso, non può creare nuovi utenti. Allo stesso modo, abbiamo ruoli amministrativi superiori agli agenti che possono creare e gestire qualsiasi ruolo agente o client, ma non possono creare altri ruoli amministrativi.

Esiste un solo account superutente che può creare e gestire utenti con ruoli amministrativi e, naturalmente, tutto il resto. (Come viene creato un superutente? Non lo è. Il nome utente e la password sono stabiliti al momento dell'installazione e tale nome utente e password sostituiscono qualsiasi ruolo o autorizzazione.)

Chiamiamo la sezione in cui gli utenti vengono creati e gestiti e, in generale, la configurazione del comportamento dell'applicazione Web per detto utente poiché questo è separato dal normale funzionamento dell'applicazione Web, il back-end. Il front-end, d'altra parte, rappresenta la parte riguardante l'acquisto e la vendita di prodotti (tutto ciò che non ha nulla a che fare con il comportamento del programma, in breve). Certo, il backend è usato tradizionalmente per indicare la parte dell'applicazione web che gli utenti non vedono, quindi forse non era il nome migliore. Tuttavia, ho pensato di condividere questo dato che potrebbe essere utile all'OP o a chiunque altro stia leggendo.