Table des matières
1. Aperçu du cycle de vie du développement logiciel
2. Classification de l'architecture du projet
3. Explication détaillée des exigences logicielles
4. Explication détaillée de l'analyse orientée objet (OOA)
Langage de modélisation unifié UML
Éléments d'un diagramme de cas d'utilisation
Fusionner les exigences pour obtenir des cas d'utilisation
Description détaillée du cas d'utilisation
Identifier les relations entre les classes
Ajouter des responsabilités aux classes
Construire un diagramme d'interaction
Spécification des exigences logicielles
1. Aperçu du cycle de vie du développement logiciel
Nous décrivons le processus de développement logiciel de manière simple et compréhensible :
- Étude de faisabilité : En termes simples, l'étude de faisabilité consiste à déterminer si le logiciel que nous souhaitons concevoir peut être réalisé à l'aide de la technologie actuelle, si le temps et le capital consommés pour l'achèvement se situent dans une fourchette raisonnable, si la fonction du logiciel peut résoudre les problèmes existants actuels, et si le logiciel actuel peut être complété, si le développement peut apporter des avantages positifs à l'entreprise.
- Analyse des exigences : analyser la fonction et l'efficacité du logiciel, qui joue un rôle décisif dans le développement de l'ensemble du logiciel, et enfin générer la spécification des exigences logicielles en fonction de la fonction et de l'efficacité du logiciel
- Outline design : concevoir la partie publique du logiciel, y compris les interfaces, les protocoles et les contraintes (contraintes globales), principalement pour une conception globale du programme, sans impliquer la mise en œuvre détaillée de chaque fonction
- Conception détaillée : conception détaillée de chaque activité et processus du logiciel, y compris le fonctionnement et la conception spécifiques de chaque activité
- Réalisation : Réaliser chaque entreprise
- Tests d'assemblage (intégration) : Déployer le logiciel et tester toutes les fonctions
- Test de confirmation : laissez l'utilisateur confirmer si toutes les fonctions répondent aux attentes et acceptez l'intégralité du logiciel
- Maintenance : grâce à diverses activités de maintenance nécessaires, le système peut répondre aux besoins des utilisateurs pendant longtemps
- Démantèlement : résiliation du support pour un produit logiciel, logiciel abandonné
2. Classification de l'architecture du projet
L'architecture des projets généraux se divise principalement en deux types : l'architecture C/S et l'architecture B/S
L'architecture C/S est un rack client/serveurL'architecture B/S est un rack navigateur/serveur
Architecture C/S
![](https://img-blog.csdnimg.cn/005561242f264340b08efcfd1ff9bdca.png)
avantage:• La plupart des activités peuvent être effectuées côté client, en utilisant pleinement les ressources informatiques locales• Réponse rapide• Forte capacité de personnalisation• Face à un groupe d'utilisateurs relativement fixe, il a une forte capacité à contrôler la sécurité de l'informationdéfaut:• Nécessité d'installer le client à utiliser• Coût de maintenance élevé, tout problème avec le client sur n'importe quel ordinateur doit être maintenu et le processus de mise à niveau est fastidieux
Structure B/S
![](https://img-blog.csdnimg.cn/05d574a9750143eb905bf827d04df2b2.png)
avantage:• Aucune maintenance côté client, il suffit d'installer un navigateur• Toutes les activités sont concentrées côté serveur, l'expansion des activités est très pratique• Faible coût de maintenance, seulement besoin de maintenir le serveurdéfaut:• Envoyer des demandes et recevoir des réponses via le réseau, qui est fortement affecté par le réseau• La sécurité des serveurs et les capacités de traitement métier nécessitent beaucoup d'efforts et de coûts• Prise en charge insatisfaisante des différents navigateurs
3. Explication détaillée des exigences logicielles
Classement des besoins
a. Exigences métier : désigne les exigences cibles de l'entreprise ou du client pour le système, généralement au sein de l'entreprise, c'est-à-dire l'activité principale du logicielb. Exigences de l'utilisateur : décrire les objectifs spécifiques des utilisateurs ou les tâches que les utilisateurs exigent que le système soit en mesure d'accomplir. (Propres besoins de l'utilisateur autres que les besoins de l'entreprise)c. Exigences du système : décrire les exigences du logiciel du point de vue du système, y compris les exigences fonctionnelles (fonctions que le système doit mettre en œuvre), les exigences non fonctionnelles(telles que la qualité du logiciel, la maintenabilité, l'efficacité, etc.) et les contraintes de conception (certaines restrictions de livraison, telles que des bases de données avec des droits de propriété intellectuelle indépendants doivent être utilisées et doivent fonctionner sous un certain système d'exploitation), etc.
acquisition de la demande
Il existe principalement les manières suivantes d'obtenir les exigences :a. Entretiens avec les utilisateurs : la méthode la plus simple.b. Enquête par questionnaire : étant donné qu'il faut du temps pour interroger les utilisateurs un par un et que le temps de l'utilisateur peut ne pas permettre une participation opportune à l'entretien, il est possible de préparer à l'avance entretien à petite échelle basé sur les résultats , qui peut être considéré comme une optimisation .c) Échantillonnage : Échantillonner une population spécifique, étudier les échantillons sélectionnés et obtenir des informations utiles. Pour le développement des systèmes d'information, les documents constituent désormais la population échantillonnée.d. Storyboard : Expliquez comment le système doit fonctionner à l'aide d'une image du système et de diapositives.
analyse de la demande
a. Dessiner le diagramme de contexte du système : un modèle simple utilisé pour définir les frontières et les interfaces entre le système et les entités externes du système, pour les exigencesDéterminer la portée ;b. Créer un prototype d'interface utilisateur : vous pouvez développer un prototype avec des outils de développement rapide ou créer un prototype de démonstration avec des outils de présentation tels que des diaporamas et Flash , et même dessiner certaines interfaces clés avec un stylo et du papier. Diagramme schématique de l'interface, afin de vous aider les utilisateurs comprennent les problèmes à résoudre et comprennent le système ;c) Analyse de faisabilité des exigences : mener des études de faisabilité sur les exigences obtenues en termes de coût, de performance et de réalisation technique, et s'il existe des conflits avec d'autres exigences, s'il existe des dépendances externes, etc. ;d) Détermination de la priorité des exigences : C'est une base importante pour formuler des plans d'itération, qui peuvent être expliqués . La satisfaction indique la satisfaction de l'utilisateur lorsque l'exigence est réalisée, et l'insatisfaction indique l' insatisfaction ;e. Construire un modèle pour les exigences : la principale forme d'expression est un diagramme plus une petite quantité de description textuelle, et la description graphique rend les exigences plus claires et plus faciles à comprendre . Le modèle d'analyse des exigences décrit principalement les données, les fonctions, l'interface utilisateur et le comportement externe du système, et n'implique pas les détails de mise en œuvre spécifiques du logiciel pour la conception ultérieure du logiciel ;f. Créer un dictionnaire de données : définir tous les éléments de données et les structures utilisées par le système pour garantir que les développeurs utilisent une définition
4. Explication détaillée de l'analyse orientée objet (OOA)
Compréhension conceptuelle :
1 Analyse orientée objet (OOA)Se produit dans la phase d'analyse des exigences pour résoudre le problème "que faire", la tâche principale est de déterminer les attributs et les méthodes de l'objet, des objets et des objetsLa relation entre chaque opération, le processus spécifique de chaque opération, mais ne tient pas compte des facteurs liés à la mise en œuvre spécifique du système ;2.2 Conception orientée objet (OOD)Se produit dans la phase de conception du système et résout le problème de "comment le faire".Ses idées de base incluent l'abstraction, l'encapsulation et l'évolutivité, et sonL'évolutivité moyenne est principalement obtenue par héritage et polymorphisme. La tâche principale est de normaliser l'ingénierie des objets d'implémentation, de gérer l'interdépendance des différentes parties du programme et de fournir des conseils et une base pour la programmation orientée objet ;2.3 La programmation orientée objet (POO) se produit pendant le développement du système, en utilisant
Langage de modélisation unifié UML
Composants importants d'UML :
◦ Objets : les objets sont également appelés éléments de modélisation, y compris les éléments structurels, les éléments comportementaux, les éléments hiérarchiques et les éléments d'annotation, qui sont les blocs de construction OO les plus élémentaires dans les modèles UML ;◦ Relation : UML utilise des relations pour combiner différentes choses. Les principales relations sont : la dépendance, l'association(association), généralisation, réalisation;◦ Diagrammes : comprennent principalement des diagrammes de classes, des diagrammes d'objets, des diagrammes de composants, des diagrammes de structure composite, des diagrammes de cas d'utilisation, des diagrammes de séquence, des diagrammes ..
Éléments d'un diagramme de cas d'utilisation
![](https://img-blog.csdnimg.cn/1a8985580c6e420089d7a7d01bb6a076.png)
Acteur : un participant est tout ce qui existe en dehors du système et interagit avec le système, il peut s'agir d'un utilisateur qui utilise le systèmeutilisateurs, ou autres systèmes et appareils externes, etc. ;Cas d'utilisation : fait référence aux actions effectuées dans le système qui se traduisent par des résultats visibles pour les acteurs. C'est-à-dire que les cas d'utilisation représentent les services fournis par le système, qui définissent comment le système est utilisé par les participants, et décrivent un dialogue entre les participants afin d'utiliser les services et l'utilisation fournis par le système ;Association de communication : elle représente la relation entre les acteurs et les cas d'utilisation, ou la relation entre les cas d'utilisation et les cas d'utilisation. La partie pointée par la flèche est le destinataire passif du dialogue et la partie pointée par la queue de la flèche est l'initiateur actif du dialogue. Si vous ne souhaitez pas mettre l'accent sur la relation active et passive dans le dialogue, vous pouvez utilisez la ligne de relation pleine sans la flèche.
identifier les participants
Les participants sont toutes les choses qui interagissent avec le système, non seulement peuvent être entreprises par des personnes, mais également par d'autres systèmes et périphériques matériels, faites attentionDe plus, les participants doivent être en dehors du système et non en faire partie. Il peut y avoir plusieurs participants exécutant des fonctions système, avec prioritéDans le même temps, l'objectif principal du développement de cas d'utilisation est de trouver les principaux acteurs.L'analyse et la découverte des acteurs du système peuvent être facilitées en posant les questions suivantes : Qui utilise le système ? Qui a installé ce système ? qui a commencédéplacer le système ? Qui maintient ce système ? Qui arrête ce système ? Quels systèmes utilisent ce système ? qui reçoit des lettres de ce systèmeintérêt? Qui fournit les informations pour ce système ?
◦ Exemple :Nous prenons comme exemple le système de forum en cours de développement, et nous avons obtenu les besoins des utilisateurs suivants à un stade précoce :▪Inscrivez-vous et connectez-vous▪Liste de publication , publication de publication, suppression de publication, réponse de publication et autres fonctions.▪ Prend en charge l'affichage/l'édition de la page d'accueil personnelle et prend en charge le téléchargement d'avatars.▪ Soutenir la classification des messages par forum.▪ Prise en charge de la publication d'émoticônes d'images▪ Prise en charge des messages privés sur le site▪ Les administrateurs peuvent ajouter/supprimer/modifier des sections▪ L'administrateur peut gérer tous les messagesSur la base de la description des exigences ci-dessus, deux participants peuvent être clairement mentionnés, l'un est un administrateur et l'autre est un utilisateur ordinaire.
Fusionner les exigences pour obtenir des cas d'utilisation
Une fois les acteurs trouvés, l'étape suivante consiste à passer en revue les acteurs et à identifier les cas d'utilisation pour chaque acteur.Tout d'abord, attribuez les exigences obtenues aux participants. Par exemple, les utilisateurs ordinaires peuvent s'inscrire, se connecter et modifier des informations personnelles.Information, publication, modification de messages auto-publiés, envoi de messages internes, etc., les administrateurs peuvent non seulement effectuer des opérations d'utilisateurs ordinaires, mais également gérer des forums, etc.Deuxièmement, effectuez des opérations de fusion d'exigences et générez des cas d'utilisation. Par exemple, pour les publications, il existe des publications de publications, des publications de modification et des publications de suppression, qui sont fusionnées dans des publications d'opération ici. Remarque : Le cas d'utilisation n'a pas besoin d'inclure un processus d'opération spécifique (flux d'événements), et le flux d'événements sera reflété dans la description détaillée du cas d'utilisation.Ensuite, les participants identifiés et les cas d'utilisation fusionnés sont exprimés sous la forme d'un diagramme de cas d'utilisation, de manière à obtenir le cadre du . Comme le montre la figure ci-dessous :
Description détaillée du cas d'utilisation
1.
Exemple de nom
|
publier un article |
2. Brève description | L'utilisateur publie un nouveau message, et en même temps augmente le nombre de messages dans le forum correspondant |
3. Flux d'événements |
1.
L'utilisateur envoie une demande au système pour publier un nouveau message
2.
Le système affiche l'interface pour l'édition de nouveaux messages
3.
L'utilisateur sélectionne la catégorie de forum correspondante, écrit le titre et le corps du message, et soumet
4.
Le système vérifie si la catégorie de bloc, le titre et le texte sont valides
5.
Le système stocke et archive les informations saisies, et la publication est publiée avec succès
|
4.
Flux d'événements alternatif
|
aucun |
5.
Exigences non fonctionnelles
|
pas d'exigences particulières |
6. Conditions préalables | Les utilisateurs doivent se connecter au système pour la vérification des autorisations |
7. Postconditions | Modifier le nombre de messages sous le forum correspondant |
8. Rallonges | ⽆ |
9. Priorité | Le plus élevé (Satisfaction 5, Insatisfaction 5) |
![](https://img-blog.csdnimg.cn/cfe20dae356342818d874cda79e4c534.png)
Définir la classe de concept
Il existe de nombreuses façons de découvrir des classes, parmi lesquelles la syntaxe de syntagme nominal est la plus largement utilisée, et les étapes spécifiques sont les suivantes :▪Lire et comprendre les documents d'exigences ou les descriptions de cas d'utilisation▪ Filtrer les noms ou les phrases nominales et créer une liste de classe initiale (classe candidate)▪Diviser les classes de candidats en trois catégories : classes évidentes, classes manifestement dénuées de sens et classes incertaines▪ Jeter les classes qui sont manifestement des catégories dénuées de sens▪ Les groupes discutent des classes de catégorie indéterminée jusqu'à ce qu'elles soient fusionnées ou ajustées aux deux autres catégories.Selon la section 4.2.4, le flux d'événements du cas de post-utilisation peut être utilisé pour obtenir une liste de classes de concepts candidats, comme suit
Identifier les relations entre les classes
![](https://img-blog.csdnimg.cn/0eaab279bd5f4f4b8ce957d28357d550.png)
◦Relation d'association : fournit la relation structurelle entre les objets de différentes classes, plutôt que la relation entre les classes. Deux objets sont généralement reliés par des verbes, par exemple, utilisateur-publier-post ; vous pouvez utiliser une S'il n'y a pas de flèche, c'est considérée comme une relation bidirectionnelle ou une association indéfinie ;◦ Relation de dépendance : deux classes A et B, si des changements dans B peuvent entraîner des changements dans A, alors la classe A est dite dépendante de B, par exemple, une classe est une donnée membre d'une autre classe, et une classe est une autre classe Un paramètre d'une opération d'une classe, etc. ;◦ Relation d'agrégation : la relation d'agrégation partagée est généralement appelée relation d'agrégation, qui représente la relation entre l'ensemble et une partie de la classe,Les "pièces" peuvent appartenir à différents "ensembles", et les cycles de vie des "pièces" et des "ensembles" peuvent être différents, par exemple, les voitures et les rouesC'est la relation d'agrégation. Une voiture a plusieurs roues. Si la voiture est cassée, la roue peut toujours être utilisée. Si la roue est cassée, vous pouvez la remplacer par une autre ;◦ Relation composite : la relation d'agrégation de combinaison est généralement appelée relation de combinaison en abrégé. Elle exprime également la relation entre le tout et la partie entre les classes. La différence avec la relation d'agrégation est que la « partie » dans la relation de combinaison peut n'appartiennent qu'à un seul « tout ». La vie des « parties » et du « tout »Le cycle est le même, par exemple : une entreprise a plusieurs départements, et il existe une relation de combinaison entre eux. Une fois l'entreprise fermée, certaines parties cesseront d' exister ;◦Relation d'implémentation : décrit la relation entre les classes et les interfaces, une classe peut implémenter les méthodes déclarées dans l'interface ;◦Relation de généralisation : elle décrit la relation entre la classe parente et la sous-classe. La relation d'héritage est la relation inverse de la relation de généralisation, c'est-à-dire que la sous-classe hérite et que la classe parente est la généralisation de la sous-classe .Pour le cas d'utilisation où les utilisateurs publient des articles, après avoir déterminé la relation entre les classes, les diagrammes de classes UML peuvent être utilisés pour , comme illustré dans la figure suivante : les utilisateurs publient des articles et les articles sont agrégés en sections.
Ajouter des responsabilités aux classes
![](https://img-blog.csdnimg.cn/d3e33977a9974cf5b3091b84ea4e604b.png)
Construire un diagramme d'interaction
![](https://img-blog.csdnimg.cn/4b42d5a7411e460587dc378f9269ce39.png)