Le cycle de vie du logiciel est divisé en étude de faisabilité, analyse des besoins, conception générale, conception détaillée, mise en œuvre, test d'assemblage (intégration),

Confirmez les 10 étapes de test, d'utilisation, de maintenance et de mise hors service, comme indiqué dans la figure ci-dessous :

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/serveur

L'architecture B/S est un rack navigateur/serveur

Architecture C/S

Le nom complet de l'architecture C/S est l'architecture client/serveur (Client/Serveur), qui est une architecture à deux niveaux couramment utilisée. Le client doit installer le client

Logiciel client, le programme serveur s'exécute sur le serveur et fournit des services de socket ou de base de données.

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'information

dé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

Le nom complet de l'architecture B/S est la structure navigateur/serveur (Browser/Server), qui est divisée en navigateurs Web, programmes serveur et serveurs de base de données.

Il peut être compris comme une amélioration de l'architecture C/S. Étant donné que toute la logique métier est traitée par le programme serveur, le client peut effectuer toutes les opérations uniquement à l'aide du navigateur, ce qui réduit considérablement les coûts de maintenance du client.

Les programmes que nous concevons actuellement en java appartiennent à l'architecture BS

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 serveur

dé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 logiciel

b. 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

Après avoir obtenu les exigences, effectuer un travail d'analyse des exigences spécifiques et enfin former la spécification des exigences logicielles en tant que livraison à l'étape suivante

réalisation

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 exigences

Dé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 objets

La 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 son

L'é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

UML (Unified Modeling Language) est un langage de modélisation facile à exprimer, puissant et universellement applicable.

La fonction ne se limite pas à prendre en charge OOA et OOD, mais prend également en charge l'ensemble du processus de développement logiciel à partir de l'analyse des besoins.

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 ..

Du point de vue de l'utilisateur, il ne veut pas comprendre la structure interne et la conception du système, ce qui l'intéresse, c'est le service que le système peut fournir.

Il enregistre les exigences obtenues auprès des utilisateurs, les synthétise et les affine, et établit des modèles de cas d'utilisation. Dans la méthode OOA, la construction d'un modèle de cas d'utilisation doit généralement passer par les étapes suivantes, respectivement, identifier les participants, fusionner les exigences pour obtenir des cas d'utilisation, affiner les descriptions de cas d'utilisation et ajuster les modèles de cas d'utilisation, dont les trois premières étapes sont nécessaires. .

Éléments d'un diagramme de cas d'utilisation

Un cas d'utilisation est une façon de décrire les exigences du système. Dans un diagramme de cas d'utilisation, il comprend principalement trois éléments : les acteurs, les cas d'utilisation et les associations de communication :

Comme le montre la figure :

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ème

utilisateurs, 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 attention

De 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ème

inté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 messages

Sur 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

La description du cas d'utilisation peut être complétée de manière itérative. Tout d'abord, préparez une description relativement détaillée pour certains cas d'utilisation importants. Pour les cas d'utilisation sans importance, vous pouvez

Pour être complétée ultérieurement, la description du cas d'utilisation comprend généralement le nom du cas d'utilisation, une brève description, le flux d'événements, les exigences non fonctionnelles, les pré- et post-

Conditions de réglage, points d'extension, priorité.

Prenant la publication dans le cas d'utilisation de la publication d'opération comme exemple, la description est la suivante :

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)

Selon l'exemple de description détaillée des cas d'utilisation ci-dessus, on peut voir que l'utilisateur doit vérifier l'état de connexion avant de publier, et l'opération de publication comprend un contrôle d'identité.

La vérification d'identité est également impliquée dans d'autres opérations, nous résumons donc un cas d'utilisation de la vérification d'identité, en utilisant un diagramme de cas d'utilisation pour décrire le cas d'utilisation

La relation entre les exemples est la suivante :

Définir la classe de concept

Classe Concept : un objet dans le modèle qui peut représenter des choses et des concepts.

La tâche principale d'OOA est de trouver les objets et les classes dans le système, et ces classes seront reflétées dans les classes logicielles dans OOD et les classes d'implémentation spécifiques dans OOP.

classe actuelle.

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

Après une analyse simple : à la fois la "catégorie du forum" et "le nombre de messages du forum" peuvent être attribués à la catégorie "forum", car la catégorie "forum"

attribut ; "post title" et "post text" peuvent être attribués à la classe "post" comme attribut de la classe "post" ; "authority

Limit" peut être attribué à la classe "User" en tant qu'attribut de la classe "User". Jusqu'à présent, pour le cas d'utilisation de la publication d'articles, trois

Les catégories sont : utilisateur, forum et publication.

Identifier les relations entre les classes

Après avoir terminé le travail de recherche de classes, il s'agit de clarifier la relation entre ces classes. La relation entre les classes comprend : association, dépendance, générique

Ils sont représentés en UML comme suit :

◦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 roues

C'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

Après avoir trouvé les classes de concept et trié la relation entre elles, vous pouvez ajouter des responsabilités aux classes, comprenant principalement deux aspects :

▪ Connaissances maintenues par la classe, c'est-à-dire variables membres ou propriétés

• Veillez à conserver des attributs simples, c'est-à-dire : ne définissez que les attributs liés aux responsabilités et aux objectifs du système ; utilisez des classes de données simples

Définition de type ; aucun attribut n'est défini pour les associations de classe.

▪ Comportements qu'une classe peut effectuer, c'est-à-dire les méthodes ou les responsabilités des membres

• Il peut être jugé en fonction du verbe, puis filtré, ce qui est similaire au processus d'identification des catégories.

À ce stade, seules certaines parties principales, évidentes et liées aux règles métier sont trouvées. Ne continuez pas à affiner à ce stade

Selon l'analyse des responsabilités de la classe, celle-ci s'exprime dans un diagramme de classe comme suit :

Construire un diagramme d'interaction

Le comportement de plusieurs objets est généralement représenté par des diagrammes d'interaction, les plus couramment utilisés dans UML sont les diagrammes de séquence, qui peuvent être utilisés dans presque tous les systèmes.

Scènes.

Les éléments de base des diagrammes de séquence sont les objets, les participants, les lignes de vie, les boîtes d'activation, les messages et les lignes de message, parmi lesquels les messages sont l'inspiration des diagrammes de séquence.

âme. En prenant le processus de connexion de l'utilisateur comme exemple, le diagramme de séquence est décrit comme suit :

Spécification des exigences logicielles

Obtenir des cas d'utilisation en identifiant les participants, en fusionnant les exigences, en affinant les descriptions de cas d'utilisation, en définissant des classes conceptuelles, en déterminant les relations entre les classes et en ajoutant

Des étapes telles que l'ajout de responsabilités et l'établissement de diagrammes d'interaction ont complété la définition des exigences et résumé les choses du monde réel dans des classes orientées objet. En même temps, les fonctions principales et la portée du système ont été déterminées. Le travail ci-dessus est La base pour écrire la spécification des exigences logicielles, tant que ces exigences sont agrégées pour former la partie exigences de la spécification des exigences logicielles.

En tant que résultat fourni lors de l'étape d'analyse des exigences, la spécification des exigences logicielles a une importance directrice importante pour la conception et le développement du système.

Ses composantes spécifiques, telles que : le périmètre, les documents de référence, les exigences, les règles d'éligibilité, la traçabilité des exigences, les problèmes non résolus, les notes, les annexes et tout autre contenu connexe, ne seront pas abordées ici, si cela vous intéresse. Les étudiants peuvent se référer aux chapitres pertinents du norme nationale

Norme nationale|GB/T 8567-2006

Explication détaillée du processus standard (cycle de vie) du développement logiciel : suivez le standard, concevez sans souci

1. Aperçu du cycle de vie du développement logiciel