Wondershare EdrawMind
Galerie de cartes mentales Analyse mentale et conception du système d'information
- 11
Analyse mentale et conception du système d'information
Il s'agit d'une carte mentale sur l'analyse et la conception du système d'information, y compris un aperçu de l'analyse et de la conception du système, une enquête sur les exigences du système, des cas d'utilisation, un modèle de domaine, etc.
Modifié à 2023-11-14 10:01:51
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
Analyse mentale et conception du système d'information
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
- Recommandé pour vous
- Contour
Système de connaissances du chef de projet système d'information (Chapitre 3 Gestion du périmètre du projet)
- 8
Système de connaissances du chef de projet système d'information (Chapitre 10 Gestion de la communication du projet et gestion des parties prenantes)
- 9
Système de connaissances du chef de projet système d'information (Chapitre 9 Gestion des ressources humaines du projet)
- 6
Système de connaissances du chef de projet système d'information (Chapitre 11 Gestion des risques du projet)
- 8
Système de connaissances du chef de projet de système d'information (Chapitre 12 Gestion des approvisionnements de projets)
- 8
Analyse et conception de systèmes d'information
chap01 Présentation de l'analyse et de la conception du système
Introduction
Il s'agit d'un ensemble de spécifications, d'orientations pour aider à développer des systèmes d'information
1.1 Développement de logiciels et analyse et conception de systèmes
application pour ordinateur
Un programme informatique qui exécute un ensemble spécifique de fonctions sur un appareil informatique
Domaine d'application moyen
Aussi appelé « application » (app)
Système d'Information
Un ensemble de composants interdépendants qui collectent, traitent, stockent et fournissent les informations nécessaires à l'exécution des tâches commerciales.
Portée plus large que « application »
Comprend les logiciels, les bases de données et les processus manuels associés
l'analyse du système
Ces activités qui permettent aux gens de comprendre et de spécifier ce qu'un système d'information doit accomplir
conception du système
Ces activités qui permettent de définir et de décrire en détail le système qui résout les exigences
L'analyse du système équivaut à dessiner un plan, tandis que la conception du système est un plan détaillé
1.2 Cycle de vie du développement du système
projet
Une tâche planifiée qui a un début et une fin et produit un certain résultat
pour le développement de systèmes d'information
Nécessite une connaissance des outils et techniques d’analyse et de conception de systèmes
SDLC (cycle de vie de développement du système), c'est-à-dire le cycle de vie du développement du système
Le cycle de vie du développement des systèmes identifie l'ensemble du processus qui comprend toutes les activités nécessaires à la création, au lancement et à la maintenance des systèmes d'information.
Toutes les activités comprennent : l'analyse du système, la conception du système, la programmation, les tests, la maintenance du système.
six processus fondamentaux
Identifier les problèmes ou les besoins et obtenir l'approbation
Planifier et suivre les projets
Découvrir et comprendre les détails d’un problème ou d’un besoin
Concevoir des composants système qui résolvent un problème ou répondent à un besoin
Construire, tester et intégrer les composants du système
Effectuer les tests du système, puis déployer la solution
processus de développement du système d'information
Une approche pratique du développement d'un système d'information spécifique (alias : méthodologie) en effectuant des tests du système puis en déployant la solution
Par exemple
Processus unifié (UP)
Programmation extrême (XP)
Processus de développement logiciel incrémental itératif Scrum
La plupart des processus/méthodes utilisent désormais le développement agile et itératif
Développement agileDéveloppement agile
Un processus de développement de systèmes d'information qui met l'accent sur la flexibilité dans l'anticipation des nouvelles exigences en cours de développement
Rapide sur pied ; réactif au changement
Ni les utilisateurs ni les membres de l'équipe ne comprennent pleinement les problèmes et les complexités du nouveau système. La planification et l'exécution du projet doivent donc tenir compte des problèmes imprévus.
Développement itératifDéveloppement itératif
Une approche du développement de systèmes dans laquelle le système « grandit » progressivement à travers de multiples itérations
Complétez une petite partie du système (mini-projet), puis répétez le processus pour affiner et en ajouter davantage, puis répétez le raffinement et ajoutez-en davantage jusqu'à ce que ce soit terminé.
Avantage
1. Certaines parties du système peuvent être déployées rapidement
2. Retirez d'abord une petite partie à développer, afin que vous puissiez trouver le plus tôt possible les problèmes difficiles du projet
Six processus fondamentaux pour itérer sur un projet
L'aire du cercle représente la charge de travail de l'itération correspondante dans ce processus.
Chaque itération exécutera plusieurs processus avec des objectifs différents.
1.5 Prendre le système commercial RMO comme exemple pour présenter le processus de développement
1.5.1 Préparation
Identifier le problème et documenter les objectifs du système (processus principal 1)
Enquête préliminaire
Traduire les résultats dans un document de vision système (SVD)
Obtenez l’approbation pour démarrer le projet (Core Process 1)
Rencontrer les principales parties prenantes, y compris la direction
Rencontrer les principales parties prenantes, y compris la direction, pour prendre des décisions et approuver les plans et les budgets.
SVD (document de vision du système)
Un document de vision du système est utilisé pour identifier les fonctionnalités qui bénéficieront à l'entreprise et celles qui seront incluses dans le système.
Faites-le en deux étapes
Élaborer un premier relevé de prestations
Ajoutez des estimations détaillées des revenus et des coûts
Se compose généralement de trois parties
Description du problème
Capacités du système
avantages commerciaux
1.5.2 Activités le premier jour
Processus de base 2 : Planification du projet
Identifier les principaux composants (domaines fonctionnels) requis
Divisez le système en sous-systèmes ou composants
Un sous-système fait partie du système global
Définir les itérations et attribuer chaque domaine fonctionnel aux itérations
Planifier une seule itération
Déterminer les tâches requises pour l'itération
Les tâches identifiées sont compilées et organisées dans une liste appelée structure de répartition du travail (WBS).
Exemple
Contenu du WBS (structure des pauses)
Base de décomposition (nom)
La base de la décomposition dépend des quatre processus fondamentaux suivants
temps requis
Ordre d'exécution
La mesure du temps requis et de la séquence d'exécution peut aider à la construction du réseau de travail ultérieur et au calcul du chemin critique (PERT).
Le chemin critique est le chemin le plus long de tout le réseau. Les processus qu'il traverse doivent être strictement exécutés. Les processus sur les autres chemins ont un certain degré de flexibilité.
Organiser et garder ces tâches organisées par date
Convertir WBS en planning
L’avantage de planifier des itérations individuelles est que le calendrier est informel et peut être ajusté pour répondre à des circonstances inattendues.
Élaborer un projet de séquence de travail
Avantages du brouillon de bon de travail
1. Aider à organiser le travail d’équipe
2. Il permet de savoir si l'itération se déroule comme prévu
3. Si le projet prend un certain temps selon ce calendrier, le chef de projet peut voir que la programmation peut nécessiter plus de temps et de ressources et peut organiser des ressources plus tôt pour aider dans cette partie du projet.
Identifier les ressources (personnes) nécessaires et organiser le personnel pour effectuer les tâches correspondantes
Identifier les membres de l'équipe et les responsabilités
1.5.3 Activités du deuxième jour
Effectuez des tâches préliminaires d’enquête pour comprendre les exigences. (Processus principal 3)
Le chapitre 2 expliquera en détail
Élaborer une liste préliminaire de cas d’utilisation et un diagramme de cas d’utilisation. (Processus principal 3)
Cas d'utilisation
Un cas d'utilisation enregistre un événement métier déclenché par un seul utilisateur et la réponse du système à cet événement.
Un cas d'utilisation fait référence à un exemple ou une situation d'utilisation du système
Par exemple : les agents d'achat "utilisent" ce système pour "interroger les fournisseurs".
Les cas d'usage sont généralement des verbes, correspondant à des exigences/fonctions
Exemple de liste de cas d'utilisation
Exemple de diagramme de cas d'utilisation
Élaborer une liste de classe préliminaire et un diagramme de classe. (Processus principal 3)
Classe d'objet
Les systèmes d’identification de classes d’objets doivent comprendre et suivre ces éléments dans le monde réel.
Les classes d'objets doivent enregistrer des informations dans le système
Exemple de liste de classe
Exemple de diagramme de classes
Il s'agit d'un diagramme de classes préliminaire, il n'y a donc que des propriétés (caractéristiques statiques)
Le diagramme de classes de conception aura des types de données d'attribut et des méthodes de classe, etc.
Le diagramme ci-dessus est développé à l'aide du langage de modélisation unifié UML.
1.5.4 Activités du troisième jour
Menez une enquête approfondie pour connaître les détails. (Processus principal 3)
Comprendre et documenter le flux de travail détaillé pour chaque cas d'utilisation. (Processus principal 3)
Développer des descriptions de cas d'utilisation et des diagrammes de flux de travail
Voici deux façons de documenter les détails d'un cas d'utilisation
Le développement de diagrammes de workflow nécessite l'utilisation de diagrammes d'activités, qui sont des diagrammes en UML.
Exemple de diagramme de flux de travail
Les ovales de la figure représentent les tâches, les losanges représentent les points de décision, les flèches représentent le flux de séquence et les flèches traversant la ligne centrale représentent l'interaction entre l'utilisateur et le système.
Définissez l’expérience utilisateur avec des écrans et des rapports. (Processus de base 3 et 4)
Définir la disposition de l'écran
1.5.5 Activités du quatrième jour
Concevoir la structure de la base de données (schéma). (Processus principal 4)
conception de table
Mots-clés et identifiants d'index
Type de propriété
intégrité référentielle
Exemple de schéma de base de données
Concevoir la structure de haut niveau du système. (Processus principal 4)
Conception architecturale globale
Définir un diagramme de classe de conception préliminaire
Exemple de diagramme de classe de conception préliminaire
Les classes de conception incluent les variables de niveau classe requises par la classe, qui affichent également les noms des méthodes importantes dans chaque classe. Les derniers éléments d'un diagramme de classes de conception sont des flèches, qui indiquent quelles classes ont accès aux méthodes de quelles autres classes.
Conception de l'architecture du sous-système
1.5.6 Activités du cinquième jour
Continuer avec la conception détaillée (CP4)
Effectuer la programmation et les tests individuels (CP5)
La conception et la programmation ne consistent pas à concevoir le tout puis à programmer, mais à concevoir une pièce, à programmer, puis à concevoir une pièce, puis à programmer à nouveau.
1.5.7 Activités du sixième jour
Tests complets du système (CP6)
Tests fonctionnels globaux du système
Tests d'acceptation des utilisateurs
Déploiement possible de systèmes partiels (CP6)
1.5.8 Bilan de la première itération
1.6 Introduction au contenu ultérieur
1.6.1 Première partie Introduction au développement de systèmes
Chapitre un
1.6.2 Activités d'analyse du système de la partie 2
Chapitres 2, 3, 4 et 5
1.6.3 Activités de conception du système de la partie 3
Chapitre six et sept
1.6.4 Projets de la partie 4 et gestion de projet
Chapitre 8 et 9
1.6.5 Partie 5 Concepts avancés et concepts de déploiement
Chapitre 10, 11, 12
chap02 Enquête sur la configuration système requise
2.1 Introduction
Dans ce chapitre, nous commençons à élargir la portée et les détails du processus SDLC pour couvrir un plus large éventail de concepts, d'outils et de techniques. Ce chapitre se concentre sur les activités d'analyse des systèmes (le troisième processus principal répertorié), et les chapitres suivants discuteront en détail des modèles développés au cours de ces activités d'analyse des systèmes. Les chapitres suivants élargissent la discussion sur d’autres processus SDLC de base.
2.2CSMS (Système complet de vente et de marketing) pour RMO
2.2.1Système d’information et architecture existants du RMO
L'architecture est divisée en deux types
architecture technologique architecture technologique
L'architecture technologique décrit l'ensemble du matériel informatique, du matériel réseau, de la topologie et des logiciels système utilisés par une organisation (tels que les systèmes d'exploitation et les systèmes de gestion de bases de données).
architecture des applications architecture des applications
L'architecture des applications décrit la manière dont les ressources logicielles sont organisées et structurées pour mettre en œuvre les systèmes d'information d'une organisation. Il décrit l'organisation des logiciels en modules et sous-systèmes, y compris les technologies de support (telles que les langages de programmation et les environnements de développement), les approches architecturales (telles que l'architecture orientée services) et les technologies d'interface utilisateur (telles que les écrans informatiques mobiles, les écrans tactiles). technologie et reconnaissance vocale).
2.1.2 Nouveau CSMS
Le nouveau système intégré de vente et de marketing comportera quatre sous-systèmes
Sous-système de vente
Sous-système de mise en œuvre des commandes
Sous-système de compte client
Sous-système marketing
2.3 Activités d'analyse du système
Il y a cinq parties principales
2.3.1 Collecter des informations détaillées
Entretiens, questionnaires, documentation, observation des processus commerciaux, recherche de fournisseurs, avis et suggestions
2.3.2 Définir les exigences
Modélisation des exigences fonctionnelles et non fonctionnelles
2.3.3 Priorisation des exigences
2.3.4 Développer les boîtes de dialogue de l'interface utilisateur
Le processus d'interaction entre les utilisateurs et le système
2.3.5 Évaluer les besoins avec les utilisateurs
Engagement des utilisateurs, feedback, adaptation aux changements
2.4 Qu'est-ce que la demande
La configuration système requise correspond à toutes les activités que le nouveau système doit exécuter ou prendre en charge, ainsi qu'aux contraintes que le nouveau système doit satisfaire.
La configuration système requise est divisée en
exigences fonctionnelles
Les exigences fonctionnelles sont les activités que le système doit effectuer (par exemple, l'entreprise à laquelle le système sera appliqué).
Nécessite que l'utilisateur exécute
Prérogatives non fonctionnelles
Les exigences non fonctionnelles sont des caractéristiques au-delà des activités que le système doit exécuter ou prendre en charge.
Tels que les indicateurs de performance, les contraintes (outils de développement, formats de données, etc.)
Vous pouvez utiliser FURPS pour diviser simplement les exigences
fonctionnalité fonctionnelle
disponibilité de la convivialité
Fiabilité
Performance
Sécurité
D'autres, comme les conditions restrictives
Prérogatives non fonctionnelles
2.5 Modèles et modélisation
Modèle
Un modèle est une représentation d’un aspect du système en cours de construction.
Type de modèle
modèle de texte
rapports, documents
modèle graphique
Diagramme schématique
modèle mathématique
formule
langage de modélisation
Le développement de nombreux modèles graphiques est implémenté via UML (Undefined Modeling Language)
UML est un ensemble de constructions et de symboles de modèles standard définis par l'Object Management Group, une organisation à but non lucratif.
2.6 Parties prenantes
Les parties prenantes sont toutes celles qui ont intérêt à la réussite de la mise en œuvre du système.
Classification des parties prenantes
parties prenantes internes
Les parties prenantes internes sont des personnes au sein de l'organisation qui interagissent avec le système ou qui ont un intérêt significatif dans son fonctionnement ou sa réussite.
parties prenantes externes
Les parties prenantes externes sont celles qui échappent au contrôle et à l'influence de l'organisation,
acteurs opérationnels
Les parties prenantes opérationnelles sont des personnes qui interagissent fréquemment avec le système dans leur travail ou dans leur vie personnelle.
Par exemple : les comptables interagissent avec les systèmes de comptabilité ou de facturation, les ouvriers d'usine interagissent avec les systèmes de planification de la production, les clients interagissent avec les vitrines Internet et les patients interagissent avec les sites Web de soins de santé, les pages Facebook ou les fils d'actualité Twitter.
Gérer les parties prenantes
Les parties prenantes de la gestion sont celles qui n'interagissent pas directement avec le système mais qui utilisent les informations produites par le système ou qui ont un intérêt financier ou autre important dans son fonctionnement et sa réussite.
Par exemple : la haute direction et le conseil d’administration d’une organisation, les régulateurs et les autorités fiscales.
Deux types d’acteurs importants
Client : la personne qui apporte un soutien financier
Personnel de support technique du système
2.7 Technologie de collecte d'informations
Les technologies de collecte d’informations comprennent
2.7.1 Mener des entretiens avec les utilisateurs et autres parties prenantes
Des analystes de systèmes sont nécessaires
Préparez des questions détaillées
sujet de question
Quel devrait être le processus commercial ?
Comment fonctionnent les processus métier
Quelles informations sont nécessaires
Type de question
questions ouvertes
questions fermées
Objet de la question : ancien système ou nouveau système
Rencontrer des utilisateurs individuels ou des groupes d'utilisateurs
Obtenez et discutez des réponses aux questions
enregistrer la réponse
Suivi des informations à utiliser lors des futurs entretiens
2.7.2 Distribuer et collecter les questionnaires
Trois types de questions
questions fermées
Regardez les problèmes de format
questions ouvertes
2.7.3 Vérifier les entrées, les sorties et le processus
Il existe deux sources d'entrée, de sortie et de processus
Dossiers commerciaux et descriptions de processus au sein de l’organisation
De l’extérieur de l’organisation – organisations professionnelles et autres entreprises du secteur
Vérifier la documentation de traitement existante
2.7.4 Observer et enregistrer les processus métier
Cela vous aidera à comprendre le fonctionnement de l'entreprise
2.7.5 Rechercher des solutions fournisseurs
Trois avantages et un danger
1. L'étude de ces solutions peut aider les utilisateurs à mieux réfléchir à la manière de mieux gérer les fonctions commerciales
2. Certaines solutions sont déjà excellentes et il est difficile de suivre la tendance sans mener de recherches.
3. Acheter une solution est moins risqué et moins cher que d’en rechercher une
Danger : se précipiter pour acheter une solution sans étudier tous les besoins du système
2.7.6 Collecter les commentaires des utilisateurs actifs
2.8 Utiliser le diagramme d'activités pour enregistrer le flux de travail
Flux de travail
Un workflow est une série d'étapes de traitement qui gèrent entièrement une transaction commerciale ou une demande client.
Diagramme d'activité
Un diagramme d'activités décrit diverses activités utilisateur (ou système), les personnes qui effectuent chaque activité et le flux séquentiel de ces activités.
Symboles et explications
Les ellipses représentent diverses activités du flux de travail. Les flèches de connexion indiquent la séquence entre les activités. Les cercles noirs indiquent le début et la fin du flux de travail. Le diamant est un point de décision auquel le processus suivra une voie ou une autre. La ligne continue épaisse est une barre de synchronisation qui peut diviser un chemin en plusieurs chemins concurrents ou recombiner des chemins concurrents. Le titre du couloir représente l'agent qui exécute l'activité. Étant donné qu'il y a généralement différents agents (c'est-à-dire des personnes) dans un flux de travail qui exécutent différentes étapes du processus de flux de travail, les symboles de couloir divisent les activités de flux de travail en groupes, indiquant quel agent effectue quelle activité.
cas d'utilisation chap03
3.1 Introduction
Comme les chapitres 4 et 5, ce chapitre présente des techniques pour documenter les exigences fonctionnelles en créant divers modèles.
Un cas d'utilisation est une activité qu'un système effectue, généralement en réponse à la demande d'un utilisateur.
Les cas d'utilisation définissent les exigences fonctionnelles
Les analystes décomposent le système en un ensemble de cas d'utilisation (décomposition fonctionnelle)
Les cas d'utilisation sont généralement nommés d'après des verbes ou des gérondifs
3.2 Cas d'utilisation et objectifs des utilisateurs
Une technique permettant de définir des cas d'utilisation est la technique des objectifs utilisateur, qui demande aux utilisateurs de décrire leurs objectifs d'utilisation d'un système nouveau ou mis à jour.
Divisé en huit étapes
Identifier tous les utilisateurs potentiels du nouveau système
Catégoriser les utilisateurs potentiels en fonction de leurs rôles fonctionnels (par exemple, transport, marketing, ventes)
Catégoriser davantage les utilisateurs potentiels par niveau organisationnel (par exemple, opérations, gestion, direction)
Pour chaque type d'utilisateur, visitez-les et trouvez une liste d'objectifs spécifiques qu'ils auront lors de l'utilisation du nouveau système (objectifs actuels et fonctionnalités innovantes qui ajoutent de la valeur)
Créer une liste préliminaire de cas d'utilisation organisés par type d'utilisateur
Recherchez des copies avec des noms de cas d'utilisation similaires et résolvez les incohérences
Déterminer où différents types d'utilisateurs nécessitent les mêmes cas d'utilisation
Examiner la liste complétée avec chaque type d'utilisateur et les parties prenantes intéressées
Généralement, seuls les événements ayant des exigences fonctionnelles sont pris en compte
Les techniques de ciblage des utilisateurs sont simples mais couramment utilisées
3.3 Cas d'utilisation et décomposition des événements
La technologie de décomposition d'événements est la technologie la plus complète pour identifier les cas d'utilisation
La technologie de décomposition d'événements détermine d'abord tous les événements métier qui entraîneront une réponse du système d'information, et chaque événement mènera à un cas d'utilisation. Commencer par des événements commerciaux aide les analystes à définir chaque cas d'utilisation au bon niveau de détail
Le processus métier essentiel (EBP) est utilisé pour déterminer le niveau de détail approprié pour un cas d'utilisation.
L'EBP est une tâche effectuée par une seule personne en un seul endroit pour répondre aux événements commerciaux, ajouter une valeur commerciale mesurable et amener le système et ses données dans un état stable et cohérent.
Chaque EBP répond à un événement commercial lorsqu'il se produit
3.3.1 Technologie de décomposition d'événements
événement
Les événements se produisent à un moment et un lieu précis, peuvent être décrits et doivent être mémorisés par le système.
3.3.2 Types d'événements
événements extérieurs
Les événements externes sont des événements qui se produisent en dehors du système, généralement initiés par des agents ou des acteurs externes.
Les agents externes (ou acteurs) sont des individus ou des unités organisationnelles qui fournissent ou reçoivent des données au système.
Par exemple
Divers processus commerciaux, tels que la passation de commandes par les utilisateurs, etc.
Les événements externes sont généralement utilisés pour répondre aux demandes des utilisateurs (acteurs) et se produisent dans des environnements d'interaction homme-machine.
Événement chronométré/heure temporaire
Événement qui se produit lorsque l’on atteint un certain moment dans le temps.
Par exemple
Envoyer régulièrement des rapports statistiques, etc.
Des événements temporaires se produisent dans le système
événement de statut
Les événements de statut se produisent lorsqu'un événement se produit dans le système et déclenche une exigence de traitement.
Causé lorsque le statut change
Généralement, il s’agit d’exigences non fonctionnelles et elles ne sont pas souvent prises en compte.
3.3.3 Définir des événements
Événement/Précondition/Réponse
Les analystes doivent considérer une séquence d'événements, puis identifier les événements qui affectent réellement le système.
séquence d'événements
Il est utile de suivre une série d'événements survenus à une entité ou un acteur externe spécifique.
Événements de dépendance technologique et contrôle du système
Parfois, les analystes s'intéressent à des événements importants pour le système mais qui ne sont pas directement liés aux utilisateurs ou aux transactions. Ces événements impliquent généralement des choix de conception ou des contrôles du système. Les analystes doivent temporairement ignorer ces événements pendant l'analyse.
Les contrôles système sont des contrôles ou des procédures de sécurité conçus pour protéger l'intégrité d'un système.
Sauvegarde des données, connexion, etc.
Pendant la phase d'analyse, nous utiliserons des hypothèses techniques idéales
L'hypothèse de la technologie parfaite stipule que les événements ne se produisent que lorsque le système doit répondre dans des conditions parfaites (par exemple, l'appareil ne tombe jamais en panne, la puissance de traitement et de stockage est illimitée et les personnes qui exploitent le système sont complètement honnêtes et ne commettent jamais d'erreurs). inclus dans le processus d’analyse.
3.3.4 Utiliser la technologie de décomposition d'événements
1. Tenir compte des événements externes dans l'environnement système qui nécessitent une réponse du système
2. Pour chaque événement externe, identifiez et nommez le cas d'utilisation requis par le système.
3. Utilisez une liste de contrôle pour prendre en compte les événements temporels qui nécessitent une réponse du système.
4. Pour chaque événement temporel, identifiez et nommez les cas d'utilisation requis par le système, puis établissez le moment qui déclenche le cas d'utilisation.
5. Tenez compte des événements d'état auxquels le système peut répondre, en particulier s'il s'agit d'un système en temps réel dans lequel les changements d'état interne ou de périphérique déclenchent des cas d'utilisation.
6. Pour chaque événement d'état, identifiez et nommez le cas d'utilisation requis par le système, puis définissez le changement d'état.
7. Après avoir défini les événements et les cas d'utilisation, vérifiez s'ils nécessitent des hypothèses techniques parfaites. N'incluez pas les événements impliquant des contrôles système tels que la connexion, la déconnexion, la modification du mot de passe et la sauvegarde ou la récupération de la base de données, car ceux-ci sont placés en tant que contrôles système.
3.4 Cas d'utilisation et CRUD
Une autre technologie importante pour valider et affiner les cas d’utilisation est la technologie CRUD.
CRUD signifie
Créer
Lire lire
Mettre à jour, mettre à jour
Supprimer, supprimer
Ce sont des opérations liées à la gestion des bases de données
Les techniques CRUD sont plus utiles lorsqu'elles sont utilisées avec des techniques de ciblage des utilisateurs à titre de vérification croisée. Au lieu de l'utiliser directement comme méthode pour identifier les cas d'utilisation, cela peut empêcher les cas d'utilisation de suivre très bien le processus métier.
Peut vérifier s'il manque des types de cas d'utilisation
Étapes technologiques CRUD
1. Identifiez toutes les entités de données ou classes de domaine impliquées dans le nouveau système.
2. Pour chaque type de données (entité de données ou classe de domaine), vérifiez que vous avez identifié des cas d'utilisation pour créer de nouvelles instances, mettre à jour des instances existantes, lire ou générer des rapports sur les valeurs d'instance et supprimer (archiver) des instances.
3. Si un cas d'utilisation requis est ignoré, ajoutez un nouveau cas d'utilisation et identifiez les parties prenantes.
4. Pour les applications intégrées, assurez-vous qu'il est clair quelle application est responsable de l'ajout et de la maintenance des données et quel système utilise uniquement les données.
3.6 Diagramme de cas d'utilisation
Les diagrammes de cas d'utilisation sont des modèles UML utilisés pour afficher graphiquement les cas d'utilisation et leurs relations avec les utilisateurs.
3.6.1 Cas d'usage, acteurs et symboles
Dans la plupart des cas d'utilisation, les personnes utilisant le système, que nous avons jusqu'à présent appelées utilisateurs, sont implicites. En UML, cette personne est appelée un acteur. Les acteurs sont souvent en dehors des limites de l’automatisation
Dans le diagramme de cas d'utilisation, le symbole humain représente l'acteur, l'ovale représente le cas d'utilisation, la bordure rectangulaire représente la limite d'automatisation et la connexion entre le cas d'utilisation et l'acteur représente quel acteur participe à quel cas d'utilisation.
Exemple
Non seulement il existe des relations entre les cas d’utilisation et les acteurs, mais il peut également y avoir des relations entre les cas d’utilisation.
Il s'agit d'une dépendance entre les cas d'utilisation et se présente sous deux formes Utilisez les flèches pointillées et << >> pour indiquer
<<inclure>>
Cela peut être compris comme une relation d'utilisation, qui fait référence à l'utilisation d'un cas d'utilisation dans un autre cas d'utilisation. Le cas d'utilisation pointé par la flèche est le cas d'utilisation utilisé (dépendant). Cette relation nécessite qu'un cas d'utilisation soit utilisé dans un autre cas d'utilisation
<<étendu>>
Cette relation indique qu'un cas d'utilisation peut utiliser un autre cas d'utilisation. Dans cette relation, il y aura ce qu'on appelle un point d'extension. Par exemple, dans un système de gestion de bibliothèque, le cas d'utilisation du retour de livres peut impliquer des amendes (délais d'attente, etc.).
Le lien entre les deux est qu'il s'agit tous deux de relations entre des cas d'utilisation, et les deux signifient l'utilisation d'un autre cas d'utilisation dans un cas d'utilisation. La différence entre les deux est que l'inclusion signifie qu'un autre UC sera certainement utilisé, tandis que l'extension nécessite de juger l'extension ; point avant de décider de l'utiliser ou non
modèle de domaine chap04
4.1 Présentation
Concepts de base : éléments du domaine problématique de l'utilisateur du système
4.2 Éléments du domaine problématique
Le domaine problématique fait référence au domaine spécifique de l'activité des utilisateurs inclus dans le nouveau système.
Les classes ou entités de domaine sont ce avec quoi les utilisateurs finaux doivent travailler dans le studio. Elles sont souvent appelées « objets » dans le domaine des problèmes du système.
Par exemple
produits, commandes, clients
4.2.1 Méthode 1 pour définir les éléments du domaine problématique - méthode de brainstorming
1. Identifiez un utilisateur et un ensemble de cas d'utilisation.
2. Réfléchissez avec les utilisateurs pour identifier les éléments impliqués dans l'exécution du cas d'utilisation, c'est-à-dire les éléments sur lesquels le système doit capturer des informations.
3. Utilisez des types d'objets (catégories) pour poser systématiquement des questions sur des objets potentiels, par exemple : Stockez-vous des informations sur des objets tangibles ? Y a-t-il des lieux concernés ? De quels rôles devez-vous vous souvenir ?
4. Continuer à travailler avec une variété d'utilisateurs et de parties prenantes pour élargir la liste de brainstorming.
5. Combinez les résultats, éliminez les doublons et dressez une première liste.
4.2.2 Méthode 2 pour définir les choses dans le domaine problématique - nom technologie
Répertoriez tous les noms mentionnés par les utilisateurs. Les noms utilisés pour décrire des événements, des cas d'utilisation ou des acteurs sont des choses potentielles.
étape
1. Identifiez tous les noms à l'aide de cas d'utilisation, d'acteurs et d'autres informations sur le système (y compris les entrées et les sorties).
2. À l'aide des systèmes existants, des procédures actuelles et d'autres informations provenant des rapports ou formulaires actuels, ajoutez des éléments ou des catégories d'informations requises. Certains de ces éléments peuvent être des éléments supplémentaires, et d'autres peuvent être des informations plus spécifiques (appelées attributs) sur des éléments que vous identifiez déjà. Affinez la liste puis notez les hypothèses ou les questions que vous souhaitez explorer.
3. Au fur et à mesure que cette liste de noms se construit, vous devrez l'affiner.
Posez les questions suivantes pour chaque nom afin de vous aider à décider s'il doit être inclus :
Est-ce quelque chose d’unique que le système doit connaître ?
Est-ce dans le cadre du système que je développe ?
Le système doit-il mémoriser plusieurs des éléments ci-dessus ?
Posez les questions suivantes sur chaque nom pour décider s'il doit être exclu :
Est-ce vraiment un synonyme de quelque chose d'autre que j'ai identifié ?
S'agit-il vraiment d'une simple sortie du système basée sur d'autres informations que j'ai identifiées ?
S'agit-il vraiment simplement d'une entrée qui aboutit à l'enregistrement d'autres informations que j'ai identifiées ?
Posez les questions suivantes sur chaque nom pour décider s'il doit être étudié :
Est-il possible que ce soient des informations spécifiques (propriétés) sur d'autres choses que j'ai identifiées ?
Si les hypothèses changent, pourrais-je en avoir besoin ?
4. Créez une liste principale de tous les noms identifiés, puis indiquez si chaque nom doit être inclus, exclu ou étudié plus en détail.
5. Passez en revue la liste avec les utilisateurs, les parties prenantes et les membres de l'équipe, puis affinez la liste des éléments du domaine problématique.
Exemple
4.2.3 Propriétés des choses
La plupart des systèmes stockent des informations spécifiques sur les transactions appelées attributs.
Un attribut qui identifie quelque chose de manière unique est appelé identifiant ou mot-clé (clé/code)
Les attributs composites sont composés de plusieurs attributs liés, tels que l'adresse, le nom complet, etc.
4.2.4 Relations entre les choses
L'association fait référence à la relation naturelle entre certaines choses.
En UML, il existe environ quatre types de relations entre les objets
association
généralisation des générations
dépendancedépendance
mettre en œuvre
détails associés
a un nom
Il y a une direction, et la chose pointée par la flèche ne peut pas voir l'autre (c'est-à-dire que l'autre dépend de la chose pointée par la flèche, et la chose pointée passe à l'autre, mais vice versa n'a aucun effet)
Par exemple, A->B est appelé A dépendant de B.
L'association est la multiplicité, c'est-à-dire la relation quantitative entre une chose et une autre chose.
exemple
Il existe des restrictions de cardinalité entre les associations
élément associé
Une association se compose de plusieurs types différents de choses, et le nombre de ces choses est l'arité de l'association.
Client et commande, relation binaire
Association entre des choses similaires, un élément
Trois types différents ou plus de choses sont liés, multiples
4.3 Diagramme Entité-Contact
Ceci est un modèle pour la modélisation de bases de données
Les rectangles représentent des entités et les lignes reliant les rectangles représentent les connexions entre les entités.
représentation symbolique
Seules les lignes verticales sont tronquées pour représenter qu'il n'y a qu'un seul
Les lignes verticales sont coupées et encerclées pour représenter 0 ou 1
Un cercle avec une croix indique 0 ou plus
Les lignes verticales coupées et les lignes bifurquées représentent un ou plusieurs
Le sens correspondant au numéro est de non signé à signé
Dans les attributs de l'entité, le code primaire (identifiant) est placé sur la première ligne, et PK est marqué pour indiquer qu'il s'agit du code primaire.
Exemple
Un client correspond à 0 à plusieurs commandes ; une commande correspond à un et un seul client.
4.4 Diagramme de classes du modèle de domaine
La classe de choses en question est appelée classe de domaine
En UML, le diagramme de classes est utilisé pour afficher les classes d'objets du système
Diagramme de classes de modèle de domaine
Utilisé pour afficher des éléments dans le domaine problématique de l'utilisateur
Diagramme de classe de conception
pour la conception
représentation symbolique
Dans un diagramme de classes, les rectangles représentent les classes et les lignes droites reliant les rectangles représentent les relations entre les classes.
Le rectangle comporte deux parties (diagramme de classes de modèle de domaine, diagramme de classes de conception composé de trois parties : nom de classe, attributs, méthodes), la partie supérieure est le nom de la classe et la partie inférieure est les attributs de la classe.
Les noms de classe et les noms d'attribut utilisent la casse camel. La première lettre du nom de classe est en majuscule et la première lettre du nom d'attribut est en minuscule.
4.4.1 Notation du diagramme de classes du modèle de domaine
symbole de multiplicité
Représente le nombre de relations entre les instances de classe, similaire à la multiplicité des diagrammes de relations d'entité
Exemple
La multiplicité ici est similaire à la cardinalité de mappage du diagramme entité-relation.
Application de diagramme de classes de domaine spécifique
Il s'agit d'un diagramme de classes de modèle de domaine pour la sélection de cours par les étudiants. Un cours peut avoir de 0 à plusieurs sections, mais une section ne peut appartenir et ne doit appartenir qu'à un seul cours et les sections ont une relation plusieurs à plusieurs et les deux peuvent être ; zéro ; il existe une classe d'association entre les étudiants et les cours, signalée par une ligne pointillée, avec un attribut de note.
4.4.2 Problèmes plus complexes concernant les classes d'objets
Il existe trois types de relations dans les classes de domaine
association
Génération de généralisation/spécialisation
La relation généralisation/spécialisation repose sur le fait que les gens classent les choses en fonction de leurs similitudes et de leurs différences.
La relation généralisation/spécialisation est utilisée pour structurer ou ordonner ces choses du plus général au plus spécifique.
Chaque classe de la hiérarchie peut avoir une classe plus générale au-dessus, appelée superclasse.
Une classe peut avoir une classe plus spécialisée en dessous, appelée sous-classe.
L'héritage permet aux sous-classes de partager les caractéristiques de leur superclasse.
Utilisez une flèche triangulaire pour pointer vers la super classe
Exemple
Utilisez l'italique pour étiqueter les classes abstraites
Les classes abstraites ne peuvent pas être instanciées et ne peuvent être héritées
Il existe également une classe concrète, qui est une classe qui peut avoir des objets instances.
Les superclasses sont parfois concrètes ou abstraites
Partie entière
La relation global/partie est utilisée pour exprimer la relation entre une classe et les autres classes contenues dans cette classe.
polymérisation
Dans une relation d'agrégation, les composants peuvent exister indépendamment
Utilisez des diamants creux pour représenter
combinaison
Dans une relation combinée, chaque partie ne peut exister indépendamment une fois liée.
Utilisez un diamant solide pour représenter
Chapitre05 Extension du modèle d'exigences
5.2 Description du cas d'utilisation
Les descriptions de cas d'utilisation décrivent les détails de chaque cas d'utilisation.
Description simple du cas d'utilisation
Convient aux scénarios uniques et à moins d'exceptions
Exemple
Description du cas d'utilisation entièrement développée
Pour certains cas d’utilisation plus complexes, une description complète du cas d’utilisation est requise.
Modèle standard
Nom du cas d'utilisation
Scénarios de cas d'utilisation
événement déclencheur
Description rapide
participants
Autres cas d'utilisation qui lui sont associés et comment il est associé
Parties prenantes
Conditions préalables
Les prérequis déterminent l'état du système au début d'un cas d'utilisation, y compris les objets qui doivent déjà exister, les informations qui doivent être disponibles et même les conditions pour les acteurs avant le début du cas d'utilisation.
Conditions ultérieures
Les postconditions déterminent ce qui doit être vrai une fois le cas d'utilisation terminé. Plus important encore, ils indiquent quels nouveaux objets le cas d'utilisation crée ou met à jour, et comment les objets doivent être liés.
flux d'activité
Flux d'activité incluant les participants (utilisateurs) et le système
situation anormale
Le flux d'activités pour chaque cas d'utilisation peut être très différent, selon l'acteur qui invoque le cas d'utilisation ; les différents flux d'activités sont appelés scénarios, également appelés instances de cas d'utilisation ;
5.3 Diagramme d'activité du cas d'utilisation
Une façon d'enregistrer les cas d'utilisation consiste à utiliser des diagrammes d'activités. Nous avons appris à utiliser des diagrammes d'activités pour créer des flux de travail au chapitre 2. Nous utiliserons ici des diagrammes d'activités pour enregistrer le flux d'activité des cas d'utilisation.
Exemple
Ce diagramme d'activité montre le flux d'activité de l'enregistrement du cas d'utilisation de l'enregistrement client.
5.4 Diagramme séquentiel du système SSD
Le diagramme de séquence du système est utilisé pour décrire le flux d'informations entrant et sortant d'un système d'automatisation.
Utilisez des symboles humains pour représenter les acteurs du cas d'utilisation et des bordures rectangulaires pour représenter les limites de l'automatisation.
Le rectangle est marqué : système (avec deux points), indiquant le système automatisé
Il y a une ligne pointillée sous les participants et le système, appelée ligne de vie, qui représente le cycle de vie des participants et du système, et le temps s'écoule de haut en bas.
Il y a l'envoi et la réception de messages entre les participants et la bouée de sauvetage du système
L'envoi des messages est représenté par un trait plein, avec la direction du participant vers le système
Les messages reçus sont représentés par des lignes pointillées avec la direction du système vers le participant
Représentation symbolique complète du message
(*)[Condition Vrai/Faux]Valeur de retour :=Nom du message (liste des paramètres)
* indique une boucle
[] représente les conditions vraies et fausses. Si l'intérieur est vrai, le message sera envoyé, sinon il ne sera pas envoyé.
Le nom du message est une description du message envoyé
La liste des paramètres est l'information à transmettre
De plus, il existe des cadres alternatifs
modification de boucle
Si plusieurs messages sont envoyés et reçus en boucle, il peut être préférable d'utiliser un framework alternatif.
Le cadre alternatif consiste à utiliser un cadre rectangulaire pour sélectionner la partie à boucler et à exprimer une boucle pour tous les éléments dans le coin supérieur gauche.
sélectionner modifier
Le cadre alternatif de select est utilisé avec else. Utilisez un cadre rectangulaire pour sélectionner la zone de sélection. Utilisez des lignes pointillées pour distinguer les messages envoyés dans différentes circonstances et marquez-les respectivement dans la partie finale du message envoyé.
5.4.2 Développer un SSD
1. Confirmez le message saisi
2. Utilisez des symboles de message pour décrire les informations transmises au système depuis l'extérieur
3. Ajoutez des conditions spécifiques au message d'entrée, y compris des boucles et des conditions vrai/faux
4. Confirmez et ajoutez un message de retour
5.5 Schéma de la machine à états Schéma de la machine à états
L'état d'un objet est une condition qui se produit au cours de sa vie lorsque certaines conditions sont remplies, certaines actions sont effectuées ou un événement est attendu.
La transition d'état est l'activité d'un objet passant d'un état à un autre.
fonction de transition d'état
Nom de la conversion (paramètre,...) [condition de jugement]/description du comportement
Une expression d'action représente un processus qui doit se produire avant que la transition ne soit terminée et que l'objet n'atteigne l'état cible.
Une condition est un qualificatif ou un test pour une transition, c'est simplement une condition vrai/faux qui doit être remplie avant que la transition puisse être déclenchée.
5.5.1 État composite et état concurrent
Être dans plusieurs états en même temps est appelé concurrence ou états concurrents.
Représenté à l'aide de chemins concurrents similaires aux diagrammes d'activités, un chemin est un ensemble ordonné de transitions d'état interconnectées.
Imbriquer les états dans d’autres états de niveau supérieur. Ces états de niveau supérieur sont appelés états composites.
L'état composite est représenté par un état de haut niveau imbriqué dans un état de niveau inférieur
Exemple
Lorsque l'imprimante est allumée (état composite), elle a deux chemins concurrents, à savoir la partie bac à papier et la partie impression. Les deux parties sont indépendantes lorsque le bouton marche est enfoncé, et lorsque le bouton arrêt est activé. enfoncé, il s'éteint. Il n'y a aucune restriction.
5.5.2 Règles de développement de diagrammes de machines à états
Affichez le diagramme de classes et sélectionnez les classes qui peuvent nécessiter un état
Pour chaque classe sélectionnée dans le groupe, répertoriez toutes les conditions de statut que vous pouvez déterminer
Commence à construire un fragment de diagramme de machine à états en identifiant les transitions qui font qu'un objet quitte l'état identifié
Organisez ces combinaisons de transitions d'état dans le bon ordre
Vérifiez ces chemins et recherchez des chemins concurrents indépendants
Trouver d'autres conversions
Développez chaque transition avec des événements de message, des conditions de garde et des expressions d'action appropriées.
Vérifiez et testez chaque diagramme de machine d'état
5.6 Intégration des modèles de demande
La relation entre les différents modèles de demande
diagramme de cas d'utilisation
Description du cas d'utilisation
Diagramme d'activité
SSD
Diagramme de classes de modèle de domaine
Schéma de la machine à états
La relation est décrite par la figure suivante
La flèche pointe dans la direction allant de l'élément dépendant à l'élément dépendant
Les lignes pleines représentent les dépendances principales, les lignes pointillées représentent les dépendances secondaires et certaines flèches sont bidirectionnelles, indiquant une influence mutuelle.
chap06 Points fondamentaux de la conception et des activités de conception
6.1 Introduction
Dans la phase d'analyse, nous discuterons principalement de ce que fait le système (comme les exigences) ; tandis que dans la phase de conception, nous discuterons principalement de la manière dont le système répond à ces exigences.
Les entrées et les sorties de la conception du système ne sont pas les entrées et les sorties du système : les entrées de la conception du système sont le résultat de l'analyse du système, c'est-à-dire les exigences et les modèles associés, tandis que les sorties de la conception du système sont une solution plus détaillée.
6.2 Éléments de conception
6.2.1 Qu'est-ce que la conception d'un système ?
La conception du système est un processus de transition entre l'analyse du système et sa mise en œuvre dans le but de définir, d'organiser et de construire les composants de la solution finale en tant que plan de construction.
6.2.2 Principaux composants et niveaux de conception
Composants principaux
conception environnementale
Décrit les réseaux, le matériel, etc. qui connectent le système entre eux
conception d'applications
Programme d'ordinateur
Design de l'interface utilisateur
Écrans, rapports et contrôles définis pour les entrées et les sorties
Conception de base de données
Structure de la base de données
Conception de l'interface système
Décrit la communication avec d'autres systèmes
Conception de sécurité et de contrôle
deux niveaux
Conception architecturale
Clarifier l'ensemble du cadre et de la forme de la solution, qui constitue la conception générale de la structure globale du système
Également appelé conception globale ou conception conceptuelle
la conception de détail
Comprend des détails de programmation spécifiques
Exemple
Conception par cas d'utilisation
Conception de base de données
Conception de l'interface utilisateur et de l'interface système
Conception de sécurité et de contrôle
6.3 Entrées et sorties de la conception du système
Convertir les informations telles que les modèles d'analyse et les documents obtenus à partir de l'analyse du système en un modèle représentant le système de solution
Modèle analytique
Diagramme de classes
Diagramme de cas d'utilisation UCD
Diagramme de séquence du système SSD
Description du cas d'utilisation
Schéma de la machine à états
Diagramme d'activité
modèle de conception
Carte des forfaits
Graphique de nœud et d'emplacement
Diagramme de classe de conception
Organigramme
Schéma de base de données
Interface utilisateur et système
Contrôle de la sécurité du système
Diagramme de collaboration
6.4 Activités de conception
Les activités de conception correspondent à la conception des six composants ci-dessus. Chaque activité de conception comporte des problèmes clés correspondants.
conception environnementale
Avons-nous détaillé l'environnement dans lequel le logiciel sera exécuté et toutes les différentes options ?
Architecture d'applications et conception de logiciels
Avons-nous détaillé tous les éléments du logiciel et comment chaque cas d'utilisation est réalisé ?
Design de l'interface utilisateur
Avons-nous détaillé comment ce système communiquera avec tous les autres systèmes à l'intérieur et à l'extérieur de l'organisation ?
Conception de l'interface système
Avons-nous détaillé comment les utilisateurs interagiront avec le système pour effectuer toutes leurs tâches [cas d'utilisation] ?
Conception de base de données
Avons-nous spécifié toutes les exigences en matière de stockage des informations, y compris tous les éléments du schéma ?
Conception de sécurité et de contrôle
Avons-nous détaillé tous les éléments requis pour garantir la sécurité et la protection des systèmes et des données ?
6.4.1 Environnement de conception
L'environnement est toute la technologie nécessaire pour prendre en charge une application logicielle
Serveur, ordinateur de bureau
appareils mobiles, systèmes d'exploitation
Capacité de communication, capacité d’entrée et de sortie
Nous l'avons appelé architecture technique au chapitre 2
6.4.2 Concevoir l'architecture des applications et les logiciels
Diviser le système en sous-systèmes
Définir l'architecture logicielle (conception architecturale)
Architecture MVC à trois niveaux, etc.
Conception détaillée de chaque cas d'utilisation
Diagramme de classe de conception
Organigramme
Schéma de la machine à états
6.4.3 Concevoir l'interface utilisateur
La conception des boîtes de dialogue commence par les exigences
La conception ajoute la disposition de l'écran, l'apparence, la navigation et l'expérience utilisateur
Concevoir différentes interfaces pour différents appareils
6.4.4 Concevoir l'interface du système
Les systèmes d’information interagissent avec de nombreux autres systèmes internes et externes
Les interfaces système se connectent à d’autres systèmes de différentes manières
6.4.5 Base de données de conception
Commencez avec un diagramme de classes de modèle de domaine (ou ERD)
Sélectionnez la structure de la base de données
Architecture de conception (distribuée, etc.)
Schéma de base de données de conception
Table, colonne d'attribut
Contraintes d'intégrité de référence de conception
6.4.6 Conception des contrôles de sécurité et du système
L'objectif est de protéger les actifs d'une organisation, essentiels dans le monde Internet et sans fil.
Contrôles de l'interface utilisateur
contrôle des applications
Contrôle de base de données
contrôle du réseau
6.5 Comment concevoir l'environnement
Concevoir sur site
Il existe deux types de systèmes logiciels sur site
Système logiciel autonome
Exécuter à partir d'un appareil sans réseau
Système interne basé sur le Web
Déploiement matériel : LAN
architecture client-serveur
Système d'application de bureau (client-serveur)
Système d'application basé sur un navigateur (navigateur-serveur)
Utiliser le langage de balisage hypertexte comme page
Utiliser le protocole TCP/IP comme protocole de transport
Architecture client/serveur à trois niveaux
Un moyen efficace de concevoir des logiciels consiste à séparer les couches d'interface utilisateur et de logique métier, ainsi que la couche de logique métier et la couche d'accès aux données. Cette méthode de conception de programmes est appelée architecture à trois niveaux. L'idée de base est de diviser le logiciel en trois couches
Couche d'affichage : responsable de la réception des entrées de l'utilisateur et de leur traitement en sortie formatée
Couche logique/Couche de domaine Couche de domaine : responsable des règles et procédures qui mettent en œuvre les processus métier ou de traitement.
Couche de données : responsable de la gestion des données stockées, qui existent généralement dans une ou plusieurs bases de données
Plusieurs niveaux peuvent s'exécuter sur un seul ordinateur, ou chaque niveau peut être exploité par un ordinateur distinct. Des niveaux complexes peuvent être déployés sur deux ou trois niveaux en distribuant les fonctionnalités du niveau ou en implémentant l'équilibrage de charge sur des ordinateurs redondants.
Une autre idée de conception est MVC, c'est-à-dire Model-View-Controller
Concevoir un déploiement externe
Les questions importantes incluent
Configuration pour le déploiement Internet
La protection des données est mise en œuvre à l'aide de Hypertext Transfer Protocol Security (HTTPS). Les pages Web desservies par le protocole HTTPS sont transmises sous une forme cryptée, plus sécurisée que HTTP.
Utilisez des structures de serveurs multiniveaux, des réseaux d'équilibrage de charge et de diffusion de contenu (CDN) pour augmenter les performances.
La structure de serveur multiniveau comprend un serveur d'applications et un serveur de base de données
Les requêtes sont envoyées à différents serveurs du centre de données via des ordinateurs d'équilibrage de charge
Lorsque vous accédez à des images ou vidéos statiques, vous pouvez utiliser un CDN indépendant pour les envoyer
Options d'hébergement pour les déploiements Internet
location de salle
Fournissez aux clients un centre de données sécurisé pour y placer des ordinateurs serveurs. L'avantage est qu'il n'y a pas de coûts de centre de données physiques, sécurisés et complexes.
Services gérés
Fournit des services supplémentaires, notamment la gestion des systèmes d'exploitation, des serveurs réseau, des serveurs de bases de données, etc. L'avantage est qu'il n'est pas nécessaire d'embaucher des employés pour gérer les systèmes serveurs et les logiciels système.
serveur virtuel
Les clients peuvent louer des serveurs virtuels de taille fixe
Cloud computing
Les clients n'ont qu'à acheter la capacité informatique dont ils ont besoin et qu'ils utilisent, et lorsque la capacité informatique augmente, le cloud fournira automatiquement plus de capacité. Cet arrangement peut permettre de réduire les coûts car il n'est pas nécessaire d'acheter de la capacité inutile ;
Pour toutes les alternatives, il existe un accord de niveau de service (Service Level Agreement), qui fait partie du contrat entre l'entreprise et l'hébergeur pour garantir un niveau spécifique de disponibilité du système.
Diversité des appareils clients déployés pour Internet
ordinateur
Tablette de taille moyenne
petit appareil mobile
Conception pour les environnements distants et distribués
Déploiement à distance via réseau privé virtuel (VPN)
Un VPN est un réseau construit sur un réseau public tel qu'Internet. Il fournit un réseau sécurisé et connectable pour les groupes privés
chap07 Concevoir l'interface utilisateur et l'interface système
7.2 Interface utilisateur et interface système
L'interface utilisateur contient des entrées et des sorties qui nécessitent une intervention directe de l'utilisateur.
L'interface système nécessite un minimum d'entrées et de sorties manuelles
7.3 Comprendre l'interface utilisateur
L'interface utilisateur comporte trois composants
Signification physique : bureaux et chaises, lampes, claviers, souris, écrans tactiles
Signification perçue : couleurs, formes, textures, polices, fenêtres, menus, boutons
Signification conceptuelle : client, participant, commande, transport, feedback
La perspective de conception de l'interface utilisateur est centrée sur l'utilisateur, mettant l'accent sur l'interaction entre l'homme et l'ordinateur (interaction homme-machine)
L'interaction homme-machine est un domaine qui étudie l'efficience et l'efficacité de l'interaction des utilisateurs avec les systèmes informatiques, les techniques d'entrée et de sortie orientées vers l'humain et les aspects psychologiques des interfaces utilisateur.
Trois principes de base de la conception centrée sur l'utilisateur
Concentrez-vous dès le début sur les utilisateurs et leur travail
Évaluer le système pour garantir sa convivialité
Utiliser le développement itératif
Métaphores de l'interaction homme-machine
Les métaphores sont des analogies entre les fonctionnalités de l'interface utilisateur et les entités physiques familières aux utilisateurs.
Les métaphores sont largement utilisées dans la conception d’interfaces utilisateur dans les situations suivantes :
manipulation directe
Manipuler des objets physiques directement sur l'écran ou des objets qui les représentent
Exemple : l'utilisateur fait glisser un dossier vers la corbeille
métaphore du bureau
Organisez l'affichage visuel en différentes zones, avec un grand espace de travail vide au milieu entouré d'un ensemble d'icônes d'outils
Exemple : bureau Windows
métaphore du document
Afficher les données comme une page ou un tableau
Exemple : document d'instructions d'utilisation, etc.
métaphore conversationnelle
Les utilisateurs et les ordinateurs accomplissent des tâches en s'engageant dans une communication ou un dialogue à l'aide de texte, de voix ou d'autres outils.
Exemple : fenêtre cmd
Les trois premiers mettent l'accent sur les objets qui interagissent avec l'utilisateur, et la métaphore conversationnelle met l'accent sur la communication qui se produit entre l'utilisateur et l'ordinateur.
7.4 Concepts de conception de l'interface utilisateur
7.4.1 Rapidité et visibilité
Indicatif fait référence à l’apparence d’un contrôle reflétant ses performances
La visibilité signifie que le contrôle est visible
7.4.2 Cohérence
7.4.3 Raccourcis
7.4.4 Commentaires
7.4.5 Dialogue complet
7.4.6 Gestion des erreurs
7.4.7 Annuler une action
7.4.8 Réduire le fardeau de la mémoire à court terme
7.5 De l'analyse à la conception de l'interface utilisateur
7.5.1 Cas d'utilisation et hiérarchie des menus
Les menus sont un moyen d'organiser un grand nombre de cas d'utilisation ou de conversations associés dans une interface utilisateur
Le concepteur doit estimer la hiérarchie des menus en fonction du nombre de cas d'utilisation
Un niveau de menu contient généralement 5 à 10 options
7.5.2 Dialogues et storyboards
Besoin d'enregistrer les conversations dont les utilisateurs ont besoin
Storyboard : Affichez cette série de croquis d'écran dans la conversation
7.6 Conception de l'interface utilisateur
7.6.1 Lignes directrices pour la conception de formulaires et de tableaux
Disposition et formatage de l'interface
Cohérence, étiquettes et titres, répartition et ordre, polices et couleurs
entrée de données
Zone de texte, zone de liste, zone de liste déroulante, bouton radio, case à cocher
Contrôle d’orientation et d’assistance
Réduire, agrandir, fermer, barres de défilement, redimensionner
7.6.2 Directives supplémentaires pour les interfaces de navigateur
cohérence
Feuilles de style en cascade (CSS) : norme de codage de pages Web qui permet aux concepteurs de sites Web de spécifier des parties d'une page qui se ressemblent toujours et des parties qui varient en fonction de la tâche ou du public.
Considérations sur les performances
Sensible aux connexions réseau, à la quantité d'informations transférées, au type d'informations transférées
Images, vidéos et sons
Il y aura des problèmes de compatibilité
Utilisateurs spéciaux (handicap)
Technologie d'assistance – logiciel qui adapte les interfaces utilisateur aux besoins particuliers des personnes handicapées (tels que les outils de synthèse vocale et de reconnaissance vocale)
7.6.3 Directives supplémentaires pour les interfaces des appareils mobiles
Défis liés à la conception d'interfaces utilisateur pour les appareils mobiles
Petits écrans, claviers et écrans tactiles, capacité réseau limitée, directives de conception d'applications et boîtes à outils
7.7 Déterminer l'interface système
Les interfaces système sont définies au sens large comme des entrées et des sorties qui ne nécessitent aucune ou peu d'intervention de l'utilisateur.
Divisé dans les catégories suivantes
Entrées et sorties d'autres systèmes
XML (Extensible Markup Language) peut être utilisé pour l'échange électronique de données et la communication inter-systèmes.
XML implémente l'intégration de structures de données personnalisées par rapport à HTML
Entrée et sortie hautement automatisées
Entrées et sorties de bases de données externes
7.8 Entrée du système de conception
7.8.1 Périphériques d'entrée automatisés
L'objectif principal de toute saisie de données est de fournir ou de mettre à jour des données sans erreur dans le système. La chose la plus importante est d'éviter les erreurs autant que possible. Voici plusieurs façons d'éviter efficacement les erreurs.
Utiliser des périphériques de saisie automatisés
Évitez autant que possible l’intervention humaine
Si les informations saisies peuvent être obtenues à partir d'une feuille de calcul, utilisez la feuille de calcul sans ressaisir les données.
Vérifier et corriger les données
7.8.2 Définir les détails des entrées du système
7.9 Résultats du système de conception
Concevoir des rapports, des relevés et des documents de retour
Type de rapport
Rapport détaillé : contient des informations détaillées sur le processus métier
Rapport de synthèse : ce type de rapport est utilisé pour résumer les activités par étapes.
Rapport d'anomalie : généré lorsque les résultats d'une transaction ou d'une opération sont anormaux.
Rapports exécutifs : évaluer la santé globale et les opérations
La sortie interne est générée pour un usage interne de l'organisation ou de l'unité. Les rapports évoqués précédemment appartiennent à la sortie interne et sont générés pour une utilisation par les membres externes de l'organisation, tels que les informations de confirmation de commande, les relevés de règlement mensuels, etc. Parce qu'il s'agit d'un document commercial officiel généré pour des étrangers et qui nécessite une qualité supérieure.
Il existe un type de sortie externe appelée document de retour. La sortie fournie à l'utilisateur consiste en une partie qui peut être déchirée et utilisée ultérieurement comme entrée dans le système, comme une facture contenant un talon de paiement qui sera retourné avec le document. vérifier.
relevés électroniques
Présentation graphique et multimédia
chap08 méthode de développement du système
8.2 Cycle de vie du développement du système
8.2.1 Méthodes traditionnelles de prédiction du cycle de vie du développement du système
La méthode de prévision est une méthode qui permet de planifier à l'avance les projets de développement organisationnel et de développer de nouveaux systèmes d'information conformément au plan.
Exigences : on suppose que le projet peut être planifié à l'avance, que le système d'information peut être développé conformément au plan, que les exigences sont bien comprises et que le risque technique est faible.
modèle de cascade
Dans un projet, les six phases du cycle de vie progressent d'une phase à la suivante et les phases sont séquentielles.
Dans le modèle traditionnel en cascade, il n'y a pas de chevauchement ni d'itération entre les différentes étapes du SDLC.
Le modèle sur le côté relativement droit de l'échelle est le modèle de cascade amélioré.
Le modèle de cascade amélioré conserve toujours la séquence prévue des phases de développement, mais ces phases se chevauchent, s'influencent et dépendent les unes des autres.
Une plus grande flexibilité, mais suppose toujours une planification prédictive et des phases séquentielles
8.2.2 Approche adaptative du cycle de vie du développement du système
Les modèles d'adaptation peuvent être utilisés pour le développement lorsque les exigences (exigences) ne sont pas claires et impliquent souvent plusieurs itérations.
Les projets doivent être plus flexibles et s'adapter aux besoins changeants au cours du processus de développement ; la demande est incertaine et les risques techniques sont élevés.
modèle en spirale
Relativement loin de l'extrémité droite de l'échelle
Utilisez une spirale pour décrire le SDLC, en partant du centre et en s'étendant vers l'extérieur encore et encore jusqu'à ce que le projet soit terminé.
Plus d'une fois par étape
modèle itératif
Semblable à la méthode de développement du chapitre 1, les lignes du tableau correspondent aux activités de développement et les colonnes aux itérations.
Chaque itération contient plusieurs étapes, et chaque étape ne sera pas complétée en une seule fois, mais sera continuellement améliorée au cours des itérations suivantes.
Concepts supplémentaires sur les approches adaptatives
développement progressif
Le concept de base est que les systèmes sont construits par petits incréments, se développant de manière organique.
Au cours du projet, le système est mis en œuvre par étapes et partiellement déployé
L'avantage est que les utilisateurs peuvent obtenir rapidement une partie du système afin de pouvoir lancer leur activité le plus rapidement possible.
squelette ambulant
Une première approche pour construire une structure de système complète mais ne fournissant que des fonctions de base
Tout d'abord, fournissez un « squelette » du processus complet de mise en œuvre du nouveau système d'avant en arrière, puis utilisez les itérations suivantes pour remplir le squelette.
Dans les projets, ce n'est souvent pas un choix extrême
8.3 Phase d'assistance
L'approche prédictive SDLC inclut une telle phase de support
L'approche adaptative traite la phase de support comme un projet complet et autonome
Trois activités principales se déroulent pendant la phase de support
Système d'entretien
Renforcer le système
Supporter les utilisateurs
8.4 Méthodes, modèles, outils et techniques
méthodes de développement de systèmes
La portée de la méthode est la plus grande
Une méthodologie comprend un ensemble de techniques pour réaliser des activités et des tâches, y compris la modélisation de chaque aspect d'un projet.
Modèle
Un modèle est une représentation abstraite d'un aspect spécifique du monde réel qui permet de comprendre un concept complexe en se concentrant uniquement sur les parties pertinentes.
Chaque modèle met l'accent sur des informations différentes
Nous avons déjà été en contact avec certains de ces modèles : diagramme ER, diagramme de cas d'utilisation, diagramme de classes, diagramme de séquence.
outil
assistance logicielle
technologie
acquis par l'apprentissage
8.5 Deux méthodes de construction et de modélisation de logiciels
8.5.1 Approche structurée
La méthode structurée se concentre sur le processus et est centrée sur le flux de données. Elle suppose que le système est un ensemble de processus qui interagissent avec le flux de données.
La méthode structurée est la même méthode traditionnelle que la méthode de prédiction SDLC.
Analyse structurée
Modélisation à l'aide d'un diagramme de flux de données
Les diagrammes ER seront également utilisés
conception structurée
Concevoir des programmes à l'aide de diagrammes de structure
Nécessite un faible couplage et une cohésion élevée
Un faible couplage signifie que les différents modules sont aussi indépendants que possible des autres modules, de sorte que la modification d'un module n'affectera pas le fonctionnement des autres modules.
Une cohésion élevée signifie que chaque module met en œuvre une tâche claire
programmation structurée
Comprend un début, une fin et trois structures : séquence, sélection, cycle
Programmation descendante/conception modulaire
8.5.2 Approche orientée objet
L'approche orientée objet considère un système comme un ensemble d'objets qui travaillent ensemble pour accomplir une certaine interaction.
Les objets sont des éléments du système qui répondent aux messages
analyse orientée objet
Le processus d'identification et de définition de cas d'utilisation et d'ensembles d'objets (classes) dans un nouveau système
conception orientée objet
Définir tous les types d'objets nécessaires pour communiquer avec les personnes et les appareils et montrer comment ils interagissent pour accomplir des tâches
Utiliser des modèles tels que des diagrammes de classes et des diagrammes de cas d'utilisation
Programmation orientée objet
Écrire des instructions pour définir la classe réelle et le rôle de chaque objet de la classe
Utiliser des modèles tels que des diagrammes de séquence et des diagrammes de classes de conception
8.6 Développement agile
Activités de développement menées dans un environnement inconnu et en évolution rapide
8.6.1 Théorie et valeur du développement agile
théorie de base
Se concentrer sur la réponse au changement plutôt que sur suivre un plan
Valoriser les individus et les interactions plutôt que les processus et les outils
Valorisez un logiciel fonctionnel par rapport à une documentation complète
Concentrez-vous sur la collaboration avec les clients plutôt que sur les négociations contractuelles
Décrire le concept des projets agiles : le chaos
C'est le chaos et l'ordre : les deux premières théories fondamentales - la domination des valeurs individuelles sur les valeurs de groupe - sont la cause du chaos, et ce chaos peut être géré avec une flexibilité croissante. Le chaos est inévitable au cours du processus de développement imprévisible. Les développeurs doivent accepter le chaos, mais il est parfois nécessaire d'utiliser d'autres méthodes et techniques bénéfiques pour ajouter de l'ordre et de la structure au projet.
Pour le dire simplement, cela signifie permettre qu’un certain chaos se produise tout en garantissant l’ordre général.
chap09 Planification de projet et gestion de projet
Ce sont les deux premières des six sections principales : identifier le problème et obtenir l'approbation, planifier et surveiller le projet.
9.2 Principes de gestion de projet
9.2.1 Exigences pour la gestion de projet
Selon les statistiques, moins d'un tiers des projets réussis
Raisons pour lesquelles certains projets échouent
Raison principale : Manque d’implication de la haute direction et de compétences en gestion
Manque de participation des groupes d'utilisateurs
9.2.2 Le rôle du chef de projet
La gestion de projet est le processus d'organisation et de direction des autres pour atteindre les résultats prévus selon un calendrier et un budget préalablement déterminés. Elle peut également être définie comme le processus de planification d'un projet, puis de son suivi et de son contrôle.
Responsabilités internes du chef de projet
Élaborer le calendrier du projet
Recruter et former les membres de l'équipe
Coordonner le travail entre les membres de l'équipe
Évaluer les risques du projet
Suivre et contrôler les jalons du projet
Gérer les personnes et les ressources
Responsabilités externes du chef de projet
Signaler l'état et l'avancement du projet
Travailler directement avec les clients et les autres parties prenantes
Déterminer les besoins en ressources et obtenir des ressources
Coordonner les relations publiques
Les chefs de projet travaillent avec divers groupes de personnes
Client : la personne qui finance le système
Comité de surveillance : composé du client et d'autres cadres supérieurs pour superviser le projet
Utilisateur : une personne qui utilise directement le système pour effectuer des tâches
Les chefs de projet ont une double fonction interne et externe
9.2.3 Gestion du projet et cérémonie (cérémonie)
Le degré de formalité d'un projet, ou rituel, a également un impact sur la gestion de projet.
Les petits projets effectuent souvent des rituels bas de gamme
Les projets plus grands et plus complexes réalisent souvent des cérémonies de haute qualité
Les rituels du projet diffèrent selon l'utilisation de méthodes prédictives traditionnelles et de méthodes adaptatives.
Les projets adaptatifs peuvent souvent être plus formels ou informels dans leurs méthodes de gestion : UP (Unified Process) est assez formel et a des rituels stricts, tandis que les méthodes itératives sont plus informelles.
9.2.4 Système de connaissances en gestion de projet
PMBOK, se compose de neuf modules
Gestion à l'échelle du projet
Gestion du temps projet
gestion des coûts du projet
Gestion de la qualité des projets
Gestion des ressources humaines de projet
Gestion de la communication du projet
gestion des risques du projet
Gestion des achats de projets
Gestion de l'intégration du projet
9.2.5 Gestion de projet agile
Gestion de projet agile
La portée n’est pas bien comprise mais doit être contrôlée
Utiliser plusieurs lignes directrices pour déterminer les priorités commerciales
Gestion agile du temps
L'horaire doit être flexible pour s'adapter aux changements
Gestion agile des coûts
Les coûts sont plus difficiles à estimer, le contrôle des coûts n'est donc pas aussi important que dans une approche prédictive.
Gestion agile des risques
Les aspects à haut risque du projet sont terminés en premier
Gestion agile de la qualité
Effectuer une évaluation de la qualité après chaque itération
9.3 Processus de base 1 : identifier le problème et obtenir l'approbation
9.3.1 Identifier le problème
Trois objectifs principaux pour développer de nouveaux systèmes
Répondre aux nouvelles opportunités de développement
occuper des parts de marché
Résoudre les problèmes commerciaux existants
Répondre aux commandes externes
Juridique, fiscal, etc.
Un moyen efficace de définir le problème consiste à créer un document de vision système (SVD)
Comprend trois parties
Description du problème
Quels sont les problèmes et les solutions ?
Capacités du système
Quelles fonctionnalités le nouveau système aura-t-il ?
avantages commerciaux
Avantages pour l'organisation (tangibles ou immatériels)
9.3.2 Quantifier les facteurs d'approbation du projet
Il faut être clair
Temps de réalisation estimé
Coûts de développement estimés
Coûts de fonctionnement estimés
Gains préalables
l'analyse coûts-avantages
quelques notions
NPV (Valeur actuelle nette) valeur actuelle nette
La valeur actuelle des avantages et des coûts d'un investissement particulier
Calculé en soustrayant les coûts à l'aide des « bénéfices actuels » (en utilisant un facteur d'actualisation)
point de recouvrement des coûts
Durant cette période, les gains en dollars compensent les coûts en dollars
Avantages tangibles
La part du bénéfice qui peut être mesurée en termes monétaires
avantages immatériels
Avantages pour l’organisation mais ne peuvent pas être mesurés quantitativement ou estimés avec précision
Améliorations des niveaux de service (d’une manière qui ne peut être mesurée en dollars)
Amélioration de la satisfaction client (non mesurable en dollars)
Survie - il faut rivaliser comme ça
Nécessité de développer une expertise interne (par exemple, projets pilotes pour les nouvelles technologies)
méthode d'analyse coût/bénéfice
Utiliser la valeur actuelle comme valeur estimée
Calculer la durée de vie du système
Calculez la période de récupération et le revenu final en accumulant la valeur actuelle nette chaque année
Exemple
La période de récupération utilise les points d'inflexion positifs et négatifs de la valeur actuelle nette accumulée comme partie entière, et la partie décimale est calculée en utilisant (dernière valeur négative/différence totale)
9.3.3 Évaluation des risques et analyse de faisabilité
Déterminer le risque et la viabilité de l’organisation
Évaluer les risques techniques et la faisabilité
Évaluer le risque et la viabilité des ressources
Déterminer les risques et la faisabilité du calendrier
9.3.4 Travailler avec les clients sur l'approbation
Examen et approbation du Comité exécutif
Les conseils d’administration doivent examiner et approuver les très grands projets
Les parties prenantes impliquées doivent comprendre ce que l’on attend d’elles
Les DSI doivent savoir quoi faire en termes de staff et de support
L’ensemble de l’organisation doit être conscient de ce projet et de son importance
9.4 Processus de base 2 : Planifier et surveiller les projets
9.4.1 Établir l'environnement du projet
Différent de la conception de l'environnement mentionnée précédemment, l'environnement du projet fait ici référence à l'environnement de travail et à la communication à l'intérieur et à l'extérieur de l'équipe, plutôt qu'à la technologie requise par le système, etc.
Dossiers et communications – Internes/Externes
Environnement de travail – Support/Équipement/Outils
PC ou poste de travail
Logiciels et outils de développement personnel
Serveur avec bibliothèque de ressources, outils de communication
Bureaux, salles de conférence, imprimantes et autres équipements
Accompagner les employés (en dehors de l'équipe)
Processus et procédures
Rapports et documentation
la programmation
test
Livrables
Contrôle du code et des versions
9.4.2 Organiser l'avancement des travaux
Utiliser le calendrier d'itération du projet pour attribuer des cas d'utilisation aux itérations
Planifiez un calendrier détaillé des tâches et des travaux qui doivent être effectués à chaque itération - utilisez un calendrier de travail détaillé
Trois étapes pour créer un planning de travail détaillé itératif
Créer une structure de répartition du travail WBS
Estimer l’effort et identifier les dépendances
Créer un calendrier à l'aide d'un graphique Gatt
La structure de répartition du travail contient
Base de décomposition
temps requis
Ordre d'exécution
Évaluez le temps en fonction des informations pertinentes de WBS et découvrez les dépendances, éventuellement en utilisant le chemin critique
Un diagramme de Gantt est un diagramme à barres avec des activités en barres et affichées sur une chronologie horizontale.
À l'exception de la première tâche, chaque tâche a une tâche prédécesseur.
La partie de couleur claire est le chemin critique, qui affecte l’ensemble du progrès et doit être surveillé de près.
9.4.3 Allocation du personnel et des ressources
cinq tâches
Créer un plan de ressources dans le projet
Identifier et solliciter des employés techniques spécifiques
Identifier et demander des employés utilisateurs spécifiques
Organiser les équipes en groupes de travail
Mettre en place des formations initiales et des exercices de team building
9.4.4 Processus de travail d'évaluation
exposition rétrospective
9.4.5 Processus de surveillance et correction
Attribuer du travail à des individus ou à des équipes
statut de collecte
La tâche a-t-elle été accomplie et l’objectif atteint ?
Analyser les anomalies
Les exceptions sont-elles importantes ?
prendre les bonnes mesures
chap10 Conception orientée objet : principes de conception
10.2 Conception orientée objet : le pont entre l'analyse et la mise en œuvre
10.3 Conception d'architecture orientée objet (conception de haut niveau)
Les systèmes logiciels sont généralement divisés en deux types
Système mono-utilisateur : exécuté sur le bureau de l'utilisateur ou sur un serveur sans partage de ressources
Systèmes au niveau de l'entreprise : les composants peuvent être partagés entre plusieurs personnes ou organisations
Système serveur/client
Système Internet (navigateur/serveur)
Trois différences fondamentales affectant la conception de l'architecture du système
État
Le client/serveur est un système basé sur l'état et les connexions client/serveur sont de longue durée
Les systèmes Internet sont des systèmes apatrides et les connexions ne durent pas à long terme
Déploiement client
Affichage direct des écrans et des tableaux
Les écrans et les tableaux sont affichés via le navigateur
Déploiement du serveur
L'application ou le client se connecte directement au serveur
Le client se connecte indirectement au serveur d'applications via le navigateur
Schéma des composants et conception de l'architecture
Un type de diagramme de conception qui montre l'architecture globale du système et les composants logiques qu'elle contient, illustrant comment le système sera mis en œuvre
Le diagramme des composants identifie les composants du système pour la logique, la réutilisabilité et la portabilité.
Les éléments de base d'un diagramme de composants sont des éléments de composants dotés d'API.
Les API sont des méthodes publiques accessibles au monde extérieur.
Il existe deux types d'API dans les diagrammes de composants
Prise d'entrée (Socket)
Port de sortie (Port)
Exemple
Cas : Conception d'une architecture à deux couches d'Internet (en fait, elle peut aussi être à trois couches)
Couche d'interface utilisateur (couche de vue)
Couche de domaine (couche logique)
Couche d'accès à la base de données (couche de données)
Représenter à l'aide de diagrammes de composants
10.4 Principes de base de la conception détaillée orientée objet
Étapes de conception détaillée orientées objet
Développer des diagrammes de classes de conception préliminaires
Utilisez les cartes CRC pour déterminer les responsabilités de classe et la coopération pour les cas d'utilisation
Développez des diagrammes de séquence détaillés pour chaque cas d'utilisation : développez d'abord des diagrammes de séquence préliminaires, puis des diagrammes de séquence multicouches.
Ajouter des caractéristiques de méthode et des informations de navigation
Divisez la solution en packages (schéma du package)
10.5 Classe de conception et diagramme de classe de conception
10.5.1 Symboles de conception
Un prototype est une manière de classer des éléments en fonction de leurs caractéristiques, représentées par <<>>
Il existe quatre types de prototypes de conception
Classe d'entité
L'identifiant de conception de la classe du domaine problématique, généralement persistant, représenté par « entité »
Les classes persistantes font référence aux classes qui contiennent encore des données après l'arrêt du système. Lors de l'implémentation de méthodes, leurs données sont écrites dans la base de données ou dans un fichier.
Exemple
Étudiants et enseignants dans le système de gestion éducative
Classe de contrôle
C'est une classe qui joue un rôle de coordination entre les classes de vues et les classes d'entités, similaires aux routeurs ou aux commutateurs, représentées par « contrôleur »
Voir la classe
Les classes de vue, ou classes limites, se trouvent sur la limite d'automatisation du système, à l'instar des zones de saisie ou des pages Web, face aux utilisateurs, et sont représentées par « limite »
Classe d'accès à la base de données
C'est une classe qui obtient les données de la base de données et les renvoie, représentée par <<dataAccess>>
Chaque classe prototype a un symbole différent
10.5.2 Représentation de la classe de conception
Définir le format des attributs dans une classe de conception
visibilité
Indique (ou -) si la propriété est accessible directement par un autre objet. Généralement privé(-) au lieu de public()
Nom de la propriété
étui camel minuscule
expression de type
classe, chaîne, entier, double, date
valeur initiale
propriété
Entre accolades, comme {key}
Définir le format de la méthode (caractéristiques de la méthode)
visibilité de la méthode
nom de la méthode
Type de valeur de retour de méthode
liste de paramètres
Exemple
Il y a deux points entre le nom et le type de la propriété, et de même entre la liste des paramètres et le type de valeur de retour de la méthode, il y a un signe égal avant la valeur initiale ;
Utilisez les noms de classe en italique pour indiquer les classes abstraites
Les classes qui autorisent uniquement l'héritage mais pas l'instanciation représentent généralement des concepts abstraits de niveau supérieur.
10.5.3 Élaborer des diagrammes de classe de conception préliminaires
Affinement des attributs
Les concepteurs déterminent les types d'attributs en fonction de leur expérience. Dans la plupart des cas, les attributs sont invisibles (privés).
Visibilité de navigation
La visibilité de la navigation indique si une classe est visible ou invisible pour une autre classe, indiquant la capacité d'un objet à voir et à interagir avec un autre objet.
Utilisez une flèche pour indiquer que la direction pointée est le côté visible
Dans cet exemple, client fait référence à la classe de vente, donc la vente est visible par le client, mais le client n'est pas visible par la vente.
Type de visibilité de navigation
Représente une relation un-à-plusieurs entre supérieurs et subordonnés, pointant généralement des supérieurs vers les subordonnés.
Association forcée, où un objet dans une classe ne peut exister sans un objet dans une autre classe, naviguant généralement d'une classe plus indépendante vers une classe dépendante
Par exemple, dans les scénarios client et vente ci-dessus, la vente n’a aucun sens lorsqu’il n’y a pas de clients.
Lorsqu'un objet nécessite des informations provenant d'un autre objet, une flèche de navigation peut être nécessaire
La visibilité de la navigation peut être bidirectionnelle
Étapes pour développer des diagrammes de cas d'utilisation préliminaires
Cas d'utilisation après cas d'utilisation, ajoutés au diagramme
Sélectionnez les classes de domaine impliquées dans le cas d'utilisation (voir l'idée de prérequis et postconditions)
Les conditions préalables et postconditions doivent figurer dans la description du cas d'utilisation au chapitre 5.
Ajoutez une classe de contrôleur pour prendre en charge le cas d'utilisation
Utiliser des lignes directrices pour déterminer les besoins initiaux en matière de visibilité de navigation et les ajouter au diagramme
Décrire les propriétés de chaque classe en détail avec visibilité et type
Notez que les associations et la multiplicité sont souvent supprimées des diagrammes de classes de conception, tout comme la navigation est soulignée dans le texte, mais elles sont souvent conservées.
Du diagramme de classes de domaine au diagramme de classes de conception préliminaire
10.6 Utilisation de cartes CRC pour une conception détaillée
La carte CRC signifie Classe, Responsabilité, Collaboration
La conception orientée objet consiste à attribuer des responsabilités aux classes et à la manière dont elles travaillent ensemble pour réaliser un cas d'utilisation.
La carte CRC est divisée en trois zones : nom de classe, nom de responsabilité et classe de coopération.
Étapes pour utiliser la carte CRC
Commencez avec un jeu de cartes CRC inutilisées et progressez d'un cas d'utilisation à l'autre.
Sélectionnez un cas d'utilisation et sélectionnez une carte comme contrôleur
Déterminez la classe de domaine qui est principalement responsable de ce cas d'utilisation. Les objets de cette classe recevront des messages du contrôleur et les écriront sur le côté gauche de la carte.
Identifiez les autres classes qui coopèrent avec la classe d'objet principale pour compléter le cas d'utilisation et écrivez-les sur le côté droit de la carte CRC.
Après avoir déterminé les catégories de coopération, effectuez les opérations ci-dessus pour chaque catégorie de coopération (déterminer les responsabilités/trouver des catégories de coopération)
Des classes d'interface utilisateur et des classes d'accès à la base de données peuvent être ajoutées de manière appropriée
Utiliser les résultats de la carte CRC pour mettre à jour le diagramme de classe de conception préliminaire
Mettre à jour la méthode : la responsabilité dans la carte CRC devient une méthode (mais il n'y a pas d'expression de visibilité et de type de retour, c'est-à-dire qu'aucune caractéristique de méthode n'est ajoutée)
Mettre à jour la visibilité de la navigation
Exemple
Diagramme de classe de conception préliminaire
Diagramme de classe de conception mis à jour
10.7 Quelques principes de conception détaillée
faible couplage
Haute cohésion
Protection variable
indirect
Responsabilités des objets
chap11 Conception orientée objet : mise en œuvre de la conception
11.2 Conception détaillée des systèmes multicouches
Modèles de conception
Modèles de conception – techniques de conception standard et modèles largement reconnus comme bonnes pratiques
Pour les problèmes courants de conception/codage, les modèles de conception suggèrent la meilleure façon de gérer le problème.
éléments de modèles de conception
Nom du schéma
Problèmes qui nécessitent des solutions
modèle de résolution de problèmes
Cas de modèle
Avantages et conséquences des modèles
Le premier exemple de modèle de conception de programmation est le modèle de contrôleur.
Les contrôleurs de cas d'utilisation sont créés artificiellement pour transmettre les messages de la couche de vue à la couche de domaine afin de réduire le couplage.
Avantages et conséquences
Réduit le couplage entre la couche de domaine et la couche de vue
fournit une couche d'indirection
Les contrôleurs et les classes de domaine sont étroitement couplés
Si vous n’y faites pas attention, le contrôleur contiendra de nombreuses logiques non pertinentes, notamment métier.
11.3 Implémentation du cas d'utilisation et diagramme de séquence SSD
Implémentation de cas d'utilisation - le processus de conception détaillée de cas d'utilisation à l'aide de diagrammes d'interaction
Il existe deux types de diagrammes d'interaction
Organigramme
Les diagrammes de séquence sont affichés en étendant le diagramme de séquence du système
afficher l'objet de calque
Objets de couche de domaine (généralement effectués en premier)
objet de couche d'accès aux données
Diagramme de collaboration
11.3.1 Comprendre les diagrammes de séquence
La différence entre le diagramme de séquence du système et le diagramme de séquence
Le diagramme de séquence du système n'a qu'un seul objet, qui représente le système : système tandis que le diagramme de séquence étend l'objet à l'intérieur du système.
Le diagramme de séquence du système n'a que deux lignes de vie, représentant les acteurs et le système ; les acteurs et chaque objet dans le diagramme de séquence ont une ligne de vie, bien que la longueur puisse être différente (le timing commence lorsque l'objet est créé)
Dans le même cas d'utilisation, la partie limite d'automatisation du diagramme de séquence du système et du diagramme de séquence est la même (l'ensemble reste inchangé), c'est-à-dire que l'entrée du système et la sortie du système vers l'extérieur sont les mêmes. même.
Les diagrammes de séquence comportent une section de bouée de sauvetage spéciale appelée bouée de sauvetage d'activité.
La ligne de vie d'activité représente la durée pendant laquelle un objet est dans l'état d'exécution actif. L'état actif dure jusqu'à ce que toutes les données soient enregistrées ou que d'autres méthodes soient appelées.
Dans ce diagramme de séquence de création d'un cas d'utilisation utilisateur : Customform et CustomHandler ont été créés et l'objet Custom est créé après la méthode createCustom, donc l'heure de début de la ligne de vie est différente et la barre rectangulaire est la ligne de vie active ;
11.3.2 Processus de conception de la mise en œuvre du cas d'utilisation
étapes de conception
Développer un diagramme de classe de conception préliminaire montrant la visibilité de la navigation
Utilisez des cartes CRC pour attribuer des fonctions aux classes dans des cas d'utilisation
Développer des diagrammes de séquence détaillés pour chaque cas d’utilisation
Diagramme de séquence préliminaire
Diagramme de séquence à plusieurs niveaux
Utilisez des cartes CRC et des diagrammes de séquence détaillés pour mettre à jour les diagrammes de classes de conception et ajouter des fonctionnalités de méthode.
Diagrammes de classes de conception de packages
11.3.3 Cas : Diagramme de classes de conception préliminaire pour la création d'un compte utilisateur
Développer un diagramme de séquence préliminaire basé sur le diagramme de classe de conception préliminaire développé précédemment
Développez le diagramme de séquence du système et marquez les objets de classe qui doivent être utilisés dans le système original :, et il y a toujours deux points devant lui.
Déterminez les messages internes entre les objets, ajoutez des messages et des activations pour compléter la collaboration
Le format du message est cohérent avec le diagramme de séquence du système : *[codition] valeur_retour :=nom_fonction (liste_paramètres) Vous pouvez également utiliser une flèche inversée en pointillés comme valeur de retour
sous-thème
11.3.5 Lignes directrices et hypothèses pour l'élaboration de diagrammes de séquence préliminaires
guide
Acceptez chaque message et identifiez les autres messages internes résultant de ce message d'entrée
Lors du traitement de chaque message, précisez l'ensemble des classes concernées
Enrichissez la structure du message, ajoutez des conditions vraies et fausses, des boucles, des valeurs de retour, des transferts de paramètres, etc.
hypothèse
Hypothèse de perfection technique
hypothèse de perfection de la mémoire
aucune hypothèse d'anomalie
11.3.6 Développement de diagrammes de séquence multicouches
Ce qui précède n'est qu'un diagramme de séquence préliminaire pour la couche de domaine (couche logique). Pour décrire les cas d'utilisation plus en détail, vous devez développer des diagrammes de séquence pour la couche d'accès aux données et la couche de visualisation.
11.4 Utiliser le diagramme de collaboration Diagramme de communication
11.5 Diagramme de classes de mise à jour et de conception de package
Mettre à jour le diagramme de classes de conception
Sur la base des informations du diagramme de séquence, ajoutez des fonctionnalités de méthode pour mettre à jour le DCD
Trois types de méthodes
Méthode constructeur : créer une nouvelle instance d'objet
Méthodes de lecture et d'écriture de données : obtenir ou mettre à jour les valeurs d'attribut
Méthodes spécifiques au cas d'utilisation : incluses dans le diagramme de classes de conception
Carte des forfaits
Un diagramme de package est un diagramme de haut niveau qui associe des groupes de classes associés
Utilisez des icônes en forme de dossier pour représenter les packages, et les classes sont placées dans les packages correspondants en fonction des couches auxquelles elles appartiennent.
Utilisez des flèches en pointillés pour indiquer les dépendances, y compris les dépendances entre classes et les dépendances entre packages.
Exemple
Diagramme de package partiel avec un seul cas d'utilisation
Diagramme du package de sous-système
11.6 Autres modèles de conception courants
adaptateur
Lorsque deux systèmes doivent être connectés mais que les interfaces entre eux ne correspondent pas, un adaptateur est nécessaire.
Connectez les interfaces incompatibles en réécrivant les données
Par exemple : face à différents fournisseurs (taxes, frais de port), il vous suffit de réécrire l'adaptateur
usine
Les classes d'usine sont utilisées pour créer de nombreux types différents d'instances de classe utilitaire
Généralement, une classe d’outils n’a besoin que d’une seule instance et la fabrique doit s’assurer qu’il n’y a qu’une seule instance.
Singleton
Un singleton possède une variable statique pointant vers une instance de lui-même. Vérifiez cette variable via une méthode. S'il est vide, vous pouvez créer une instance et l'affecter à la variable ; s'il n'est pas vide, vous pouvez directement renvoyer l'instance de variable.
Connexion de classe{ conn statique privé = null ; getConnection() statique synchronisée publique(){ si conn==null{ conn=nouvelle connexion(); } connexion de retour ; } }
Usine et singleton
La logique de base des usines et des singletons est la même : les deux doivent garantir qu'il n'y a qu'une seule instance de l'objet et économiser la mémoire.
Mais la fabrique doit être responsable de plusieurs classes ; le singleton vérifie uniquement les variables d’instance statiques à l’intérieur de la classe.