Voir le modèle - View model
Un modèle de vue ou un cadre de points de vue en ingénierie système , en génie logiciel et en ingénierie d'entreprise est un cadre qui définit un ensemble cohérent de vues à utiliser dans la construction d'une architecture système , d'une architecture logicielle ou d' une architecture d'entreprise . Une vue est une représentation d'un système entier du point de vue d'un ensemble de préoccupations connexes.
Depuis le début des années 1990, un certain nombre d'efforts ont été déployés pour prescrire des approches de description et d'analyse des architectures de système. Ces efforts récents définissent un ensemble de vues (ou points de vue). Ils sont parfois appelés cadres d'architecture ou cadres d'architecture d' entreprise , mais sont généralement appelés «modèles de vue».
Habituellement, une vue est un produit de travail qui présente des données d'architecture spécifiques pour un système donné. Cependant, le même terme est parfois utilisé pour désigner une définition de vue , y compris le point de vue particulier et les conseils correspondants qui définissent chaque vue concrète. Le terme modèle de vue est lié aux définitions de vue.
Aperçu
Le but des vues et des points de vue est de permettre aux humains d'appréhender des systèmes très complexes , d'organiser les éléments du problème et de la solution autour de domaines d' expertise et de séparer les préoccupations . Dans l' ingénierie de systèmes physiquement intensifs, les points de vue correspondent souvent aux capacités et aux responsabilités au sein de l'organisation d'ingénierie.
Les spécifications système les plus complexes sont si étendues qu'aucune personne ne peut comprendre pleinement tous les aspects des spécifications. De plus, nous avons tous des intérêts différents dans un système donné et des raisons différentes pour l' examen du système de cahier des charges . Un dirigeant d' entreprise posera différentes questions sur la composition d'un système que ne le ferait un exécutant de système. Le concept de cadre de points de vue est donc de fournir des points de vue séparés sur la spécification d'un système complexe donné afin de faciliter la communication avec les parties prenantes. Chaque point de vue satisfait un public intéressé par un ensemble particulier d'aspects du système. Chaque point de vue peut utiliser un langage de point de vue spécifique qui optimise le vocabulaire et la présentation pour le public de ce point de vue. La modélisation des points de vue est devenue une approche efficace pour faire face à la complexité inhérente aux grands systèmes distribués.
Les pratiques de description d'architecture, telles que décrites dans IEEE Std 1471-2000 , utilisent plusieurs vues pour traiter plusieurs domaines de préoccupation, chacun se concentrant sur un aspect spécifique du système. Le modèle de vue «4 + 1» de Kruchten , le Zachman Framework , TOGAF , DoDAF et RM-ODP sont des exemples de cadres d'architecture utilisant plusieurs vues .
Histoire
Dans les années 1970, des méthodes ont commencé à apparaître en génie logiciel pour la modélisation à vues multiples. Douglas T. Ross et KE Schoman en 1977 introduisent le contexte, le point de vue et le point de vue des constructions pour organiser le processus de modélisation dans la définition des exigences des systèmes. Selon Ross et Schoman, un point de vue "précise quels aspects sont considérés comme pertinents pour atteindre ... l'objectif global [du modèle]" et détermine comment regardons-nous [un sujet modélisé]?
À titre d'exemples de points de vue, le document propose: des points de vue techniques, opérationnels et économiques. En 1992, Anthony Finkelstein et d'autres ont publié un article très important sur les points de vue. Dans ce travail: «Un point de vue peut être considéré comme une combinaison de l'idée d'un« acteur », d'une« source de connaissances », d'un« rôle »ou d'un« agent »dans le processus de développement et de l'idée d'une« vue »ou d'une« perspective "Qu'un acteur maintient." Une idée importante dans cet article était de distinguer «un style de représentation , le schéma et la notation par lesquels le point de vue exprime ce qu'il peut voir» et «une spécification , les déclarations exprimées dans le style du point de vue décrivant des domaines particuliers». Des travaux ultérieurs, tels que IEEE 1471 , ont conservé cette distinction en utilisant deux termes distincts: point de vue et vue, respectivement.
Depuis le début des années 1990, un certain nombre d'efforts ont été déployés pour codifier les approches de description et d'analyse des architectures système. Ceux-ci sont souvent appelés cadres d'architecture ou parfois ensembles de points de vue . Beaucoup d'entre eux ont été financés par le Département américain de la défense , mais certains sont le fruit d'efforts internationaux ou nationaux de l' ISO ou de l' IEEE . Parmi ceux - ci, l'IEEE pratique recommandée pour la description architecturale des systèmes intensifs-logiciels ( IEEE Std 1471-2000 ) établi des définitions de vue utiles, point de vue, les parties prenantes et les préoccupations et les lignes directrices pour la documentation d' une architecture du système grâce à l'utilisation de vues multiples en appliquant des points de vue à répondre aux préoccupations des parties prenantes . L'avantage des vues multiples est que les exigences cachées et les désaccords des parties prenantes peuvent être découverts plus facilement. Cependant, des études montrent qu'en pratique, la complexité supplémentaire de la réconciliation de plusieurs points de vue peut miner cet avantage.
IEEE 1471 (maintenant ISO / CEI / IEEE 42010: 2011 , Ingénierie des systèmes et du logiciel - Description de l'architecture ) prescrit le contenu des descriptions d'architecture et décrit leur création et leur utilisation dans un certain nombre de scénarios, y compris la conception précédente et sans précédent, la conception évolutive et la capture de conception des systèmes existants. Dans tous ces scénarios, le processus global est le même: identifier les parties prenantes , susciter des préoccupations, identifier un ensemble de points de vue à utiliser, puis appliquer ces spécifications de points de vue pour développer l'ensemble des points de vue pertinents pour le système d'intérêt. Plutôt que de définir un ensemble particulier de points de vue, la norme fournit des mécanismes et des exigences uniformes aux architectes et aux organisations pour définir leurs propres points de vue. En 1996, le modèle de référence ISO pour le traitement distribué ouvert ( RM-ODP ) a été publié afin de fournir un cadre utile pour décrire l'architecture et la conception de systèmes distribués à grande échelle.
Afficher les sujets du modèle
Vue
Une vue d'un système est une représentation du système du point de vue d'un point de vue. Ce point de vue sur un système implique une perspective se concentrant sur des préoccupations spécifiques concernant le système, qui supprime les détails pour fournir un modèle simplifié n'ayant que les éléments liés aux préoccupations du point de vue. Par exemple, un point de vue de la sécurité se concentre sur les problèmes de sécurité et un modèle de point de vue de la sécurité contient les éléments qui sont liés à la sécurité à partir d'un modèle plus général d'un système.
Une vue permet à un utilisateur d'examiner une partie d'une zone d'intérêt particulière. Par exemple, une vue d'informations peut présenter toutes les fonctions, organisations, technologies, etc. qui utilisent une information particulière, tandis que la vue organisationnelle peut présenter toutes les fonctions, technologies et informations intéressant une organisation particulière. Dans le cadre de Zachman, les vues comprennent un groupe de produits de travail dont le développement nécessite une expertise analytique et technique particulière car ils se concentrent sur le «quoi», «comment», «qui», «où», «quand» ou «pourquoi» de l’entreprise. Par exemple, les produits de travail Functional View répondent à la question «Comment la mission est-elle effectuée?» Ils sont plus facilement développés par des experts en décomposition fonctionnelle à l' aide de la modélisation des processus et des activités. Ils montrent l'entreprise du point de vue des fonctions. Ils peuvent également montrer des éléments d'organisation et d'information, mais uniquement en ce qui concerne les fonctions.
Points de vue
En ingénierie des systèmes, un point de vue est un cloisonnement ou une restriction des préoccupations dans un système. L'adoption d'un point de vue est utilisable pour que les questions relatives à ces aspects puissent être traitées séparément. Une bonne sélection de points de vue divise également la conception du système en domaines d'expertise spécifiques.
Les points de vue fournissent les conventions, règles et langages pour la construction, la présentation et l'analyse des vues. Dans l'ISO / CEI 42010: 2007 ( IEEE-Std-1471-2000 ), un point de vue est une spécification pour une vue individuelle. Une vue est une représentation d'un système entier du point de vue d'un point de vue. Une vue peut être constituée d'un ou plusieurs modèles architecturaux . Chacun de ces modèles architecturaux est développé en utilisant les méthodes établies par son système architectural associé, ainsi que pour le système dans son ensemble.
Modélisation des perspectives
La modélisation des perspectives est un ensemble de différentes manières de représenter des aspects présélectionnés d'un système. Chaque perspective a un objectif, une conceptualisation, un dévouement et une visualisation différents de ce que le modèle représente.
Dans les systèmes d'information , la manière traditionnelle de diviser les perspectives de modélisation est de distinguer les perspectives structurelles, fonctionnelles et comportementales / processuelles. Ceci, avec les perspectives de règle, d'objet, de communication et d'acteur et de rôle, est une façon de classer les approches de modélisation
Modèle de point de vue
Dans n'importe quel point de vue donné, il est possible de créer un modèle du système qui ne contient que les objets visibles de ce point de vue, mais qui capture également tous les objets, relations et contraintes présents dans le système et pertinents pour ce point de vue. Un tel modèle est dit être un modèle de point de vue, ou une vue du système de ce point de vue.
Une vue donnée est une spécification du système à un niveau particulier d'abstraction d'un point de vue donné. Différents niveaux d'abstraction contiennent différents niveaux de détails. Les vues de niveau supérieur permettent à l'ingénieur de façonner et de comprendre l'ensemble de la conception et d'identifier et de résoudre les problèmes dans leur ensemble. Les vues de niveau inférieur permettent à l'ingénieur de se concentrer sur une partie de la conception et de développer les spécifications détaillées.
Dans le système lui-même, cependant, toutes les spécifications apparaissant dans les différents modèles de points de vue doivent être abordées dans les composants réalisés du système. Et les spécifications d'un composant donné peuvent être tirées de nombreux points de vue différents. D'autre part, les spécifications induites par la répartition des fonctions sur des composants spécifiques et des interactions de composants refléteront généralement une répartition des préoccupations différente de celle reflétée dans les points de vue d'origine. Ainsi, des points de vue supplémentaires, répondant aux préoccupations des composants individuels et de la synthèse ascendante du système, peuvent également être utiles.
Description de l'architecture
Une description d'architecture est une représentation d'une architecture système, à tout moment, en termes de ses composants, comment ces composants fonctionnent, les règles et contraintes sous lesquelles ces composants fonctionnent, et comment ces parties sont liées les unes aux autres et à l'environnement. Dans une description d' architecture, les données d'architecture sont partagées entre plusieurs vues et produits.
Au niveau de la couche de données se trouvent les éléments de données d'architecture et leurs attributs et relations qui les définissent. Au niveau de la couche de présentation se trouvent les produits et les vues qui prennent en charge un moyen visuel de communiquer et de comprendre le but de l'architecture, ce qu'elle décrit et les diverses analyses architecturales effectuées. Les produits permettent de visualiser les données d'architecture sous forme de représentations graphiques, tabulaires ou textuelles. Les vues offrent la possibilité de visualiser les données d'architecture qui découlent des produits, en organisant logiquement les données pour une perspective spécifique ou holistique de l'architecture.
Types de modèles de vue système
Approche à trois schémas
L' approche à trois schémas pour la modélisation des données, introduite en 1977, peut être considérée comme l'un des premiers modèles de vue. Il s'agit d'une approche de la construction de systèmes d'information et de gestion de l'information des systèmes, qui promeut le modèle conceptuel comme la clé de l'intégration des données . L'approche à trois schémas définit trois schémas et vues:
- Schéma externe pour les vues utilisateur
- Le schéma conceptuel intègre des schémas externes
- Schéma interne qui définit les structures de stockage physique
Au centre, le schéma conceptuel définit l' ontologie des concepts tels que les utilisateurs y pensent et en parlent. Le schéma physique décrit les formats internes des données stockées dans la base de données et le schéma externe définit la vue des données présentées aux programmes d'application . Le cadre a tenté d'autoriser l'utilisation de plusieurs modèles de données pour les schémas externes.
Au fil des ans, les compétences et l'intérêt pour la construction de systèmes d'information se sont considérablement développés. Cependant, pour l'essentiel, l'approche traditionnelle des systèmes de construction s'est concentrée uniquement sur la définition des données à partir de deux vues distinctes, la «vue utilisateur» et la «vue ordinateur». Du point de vue de l'utilisateur, que l'on appellera le «schéma externe», la définition des données se situe dans le contexte de rapports et d'écrans conçus pour aider les individus à faire leur travail spécifique. La structure requise des données d'une vue d'utilisation change avec l'environnement commercial et les préférences individuelles de l'utilisateur. À partir de la vue de l'ordinateur, que l'on appellera le «schéma interne», les données sont définies en termes de structures de fichiers pour le stockage et la récupération. La structure requise des données pour le stockage informatique dépend de la technologie informatique spécifique employée et de la nécessité d'un traitement efficace des données.
4 + 1 modèle de vue de l'architecture
4 + 1 est un modèle de vue conçu par Philippe Kruchten en 1995 pour décrire l'architecture des systèmes logiciels intensifs, basée sur l'utilisation de vues multiples et simultanées. Les vues sont utilisées pour décrire le système du point de vue de différentes parties prenantes, telles que les utilisateurs finaux, les développeurs et les chefs de projet. Les quatre vues du modèle sont les vues logique, de développement, de processus et physique:
Les quatre vues du modèle concernent:
- Vue logique : concerne les fonctionnalités que le système fournit aux utilisateurs finaux.
- Vue développement : illustre un système du point de vue des programmeurs et s'intéresse à la gestion des logiciels.
- Vue de processus : traite de l'aspect dynamique du système, explique les processus du système et comment ils communiquent, et se concentre sur le comportement d'exécution du système.
- Vue physique : représente le système du point de vue d'un ingénieur système. Il concerne la topologie des composants logiciels sur la couche physique, ainsi que la communication entre ces composants.
En outre, des cas d'utilisation ou des scénarios sélectionnés sont utilisés pour illustrer l'architecture. Par conséquent, le modèle contient 4 + 1 vues.
Types de vues d'architecture d'entreprise
Le cadre d'architecture d'entreprise définit comment organiser la structure et les vues associées à une architecture d'entreprise . Étant donné que la discipline de l'architecture et de l'ingénierie d'entreprise est si vaste et que les entreprises peuvent être grandes et complexes, les modèles associés à cette discipline ont également tendance à être vastes et complexes. Pour gérer cette échelle et cette complexité, un cadre d'architecture fournit des outils et des méthodes qui peuvent concentrer la tâche et permettre la production d'artefacts précieux au moment où ils sont le plus nécessaires.
Les cadres d'architecture sont couramment utilisés dans les technologies de l' information et la gouvernance des systèmes d'information . Une organisation peut souhaiter exiger que certains modèles soient produits avant qu'une conception de système puisse être approuvée. De même, ils peuvent souhaiter spécifier certaines vues à utiliser dans la documentation des systèmes achetés - le Département américain de la Défense stipule que des vues DoDAF spécifiques doivent être fournies par les fournisseurs d'équipement pour les projets d'investissement supérieurs à une certaine valeur.
Cadre Zachman
Le Zachman Framework , conçu à l'origine par John Zachman chez IBM en 1987, est un framework pour l'architecture d'entreprise, qui fournit une manière formelle et hautement structurée de visualiser et de définir une entreprise.
Le cadre est utilisé pour organiser les «artefacts» architecturaux de manière à prendre en compte à la fois les cibles de l'artefact (par exemple, le propriétaire et le constructeur de l'entreprise) et le problème particulier (par exemple, les données et les fonctionnalités) qui est traité. Ces artefacts peuvent inclure des documents de conception, des spécifications et des modèles.
Le Framework Zachman est souvent référencé comme une approche standard pour exprimer les éléments de base de l'architecture d'entreprise . Le Zachman Framework a été reconnu par le gouvernement fédéral américain comme ayant "... reçu une acceptation mondiale en tant que cadre intégré de gestion du changement dans les entreprises et les systèmes qui les soutiennent".
Vues RM-ODP
Le modèle de référence de l'Organisation internationale de normalisation (ISO) pour le traitement distribué ouvert ( RM-ODP ) spécifie un ensemble de points de vue pour partitionner la conception d'un système logiciel / matériel distribué. Étant donné que la plupart des problèmes d'intégration surviennent lors de la conception de tels systèmes ou dans des situations très analogues, ces points de vue peuvent s'avérer utiles pour séparer les problèmes d'intégration. Les points de vue RMODP sont:
- le point de vue de l' entreprise , qui s'intéresse à l'objectif et aux comportements du système en ce qui concerne l'objectif commercial et les processus commerciaux de l'organisation
- le point de vue informationnel , qui concerne la nature des informations traitées par le système et les contraintes d'utilisation et d'interprétation de ces informations
- le point de vue informatique , qui concerne la décomposition fonctionnelle du système en un ensemble de composants qui présentent des comportements spécifiques et interagissent aux interfaces
- le point de vue de l' ingénierie , qui concerne les mécanismes et les fonctions nécessaires pour supporter les interactions des composants de calcul
- le point de vue technologique , qui concerne le choix explicite des technologies pour la mise en œuvre du système, et en particulier pour les communications entre les composants
RMODP définit en outre une exigence pour qu'une conception contienne des spécifications de cohérence entre les points de vue, notamment:
- l'utilisation d'objets et de processus d'entreprise dans la définition des unités d'information
- l'utilisation d'objets et de comportements d'entreprise pour spécifier les comportements des composants de calcul, et l'utilisation des unités d'information dans la définition d'interfaces de calcul
- l'association des choix d'ingénierie avec les interfaces de calcul et les exigences de comportement
- la satisfaction des besoins d'information, de calcul et d'ingénierie dans les technologies choisies
Vues DoDAF
Le cadre d'architecture du ministère de la Défense (DoDAF) définit une manière standard d'organiser une architecture d'entreprise (EA) ou une architecture de systèmes en vues complémentaires et cohérentes. Il est particulièrement adapté aux grands systèmes avec des défis complexes d'intégration et d'interopérabilité, et est apparemment unique dans son utilisation de « vues opérationnelles » détaillant le domaine d'exploitation du client externe dans lequel le système en développement fonctionnera.
Le DoDAF définit un ensemble de produits qui agissent comme des mécanismes pour visualiser, comprendre et assimiler la vaste portée et les complexités d'une description d'architecture par des moyens graphiques, tabulaires ou textuels. Ces produits sont organisés sous quatre vues:
- Vue d'ensemble globale (AV),
- Vue opérationnelle (OV),
- System View (SV) et le
- Vue des normes techniques (TV).
Chaque vue représente certaines perspectives d'une architecture comme décrit ci-dessous. Seul un sous-ensemble de l'ensemble de vues DoDAF complet est généralement créé pour chaque développement de système. La figure représente les informations qui relient la vue opérationnelle, la vue des systèmes et des services et la vue des normes techniques. Les trois points de vue et leurs interrelations induits - par des éléments de données d'architecture commune - fournissent la base pour dériver des mesures telles que l'interopérabilité ou la performance, et pour mesurer l'impact des valeurs de ces métriques sur la mission opérationnelle et l'efficacité des tâches.
Vues de l'architecture d'entreprise fédérale
Dans l' architecture d' entreprise fédérale américaine, l'architecture d' entreprise, de segment et de solution offre des perspectives commerciales différentes en variant le niveau de détail et en répondant à des problèmes connexes mais distincts. Tout comme les entreprises sont elles-mêmes organisées de manière hiérarchique, les différentes vues fournies par chaque type d'architecture le sont aussi. Le Federal Enterprise Architecture Practice Guidance (2006) a défini trois types d'architecture:
- L'architecture d'entreprise,
- Architecture de segment, et
- Architecture de la solution.
Par définition, l'architecture d'entreprise (EA) est fondamentalement concernée par l'identification des actifs communs ou partagés - qu'il s'agisse de stratégies, de processus métier, d'investissements, de données, de systèmes ou de technologies. L'EE est motivée par la stratégie; il aide une agence à déterminer si ses ressources sont correctement alignées sur la mission et les buts et objectifs stratégiques de l'agence. Du point de vue de l'investissement, l'EA est utilisée pour prendre des décisions concernant le portefeuille d'investissement informatique dans son ensemble. Par conséquent, les principales parties prenantes de l'EE sont les cadres supérieurs et les cadres chargés de veiller à ce que l'agence remplisse sa mission de la manière la plus efficace et la plus efficiente possible.
En revanche, l'architecture de segment définit une feuille de route simple pour une zone de mission principale, un service métier ou un service d'entreprise. L'architecture de segment est pilotée par la gestion d'entreprise et fournit des produits qui améliorent la prestation de services aux citoyens et au personnel des agences. Du point de vue de l’investissement, l’architecture de segment détermine les décisions relatives à une analyse de rentabilisation ou à un groupe d’analyses de rentabilité prenant en charge un domaine de mission principal ou un service commun ou partagé. Les principaux intervenants de l'architecture de segment sont les propriétaires et les gestionnaires d'entreprise. L'architecture de segment est liée à l'EE à travers trois principes: la structure, la réutilisation et l'alignement. Premièrement, l'architecture de segment hérite du cadre utilisé par l'AE, bien qu'elle puisse être étendue et spécialisée pour répondre aux besoins spécifiques d'une zone de mission centrale ou d'un service commun ou partagé. Deuxièmement, l'architecture de segment réutilise des actifs importants définis au niveau de l'entreprise, notamment: les données; processus commerciaux et investissements communs; et applications et technologies. Troisièmement, l'architecture des segments s'aligne sur les éléments définis au niveau de l'entreprise, tels que les stratégies commerciales, les mandats, les normes et les mesures de performance.
Ensemble nominal de vues
A la recherche de "Framework for Modeling Space Systems Architectures", Peter Shames et Joseph Skipper (2006) ont défini un "ensemble nominal de vues", dérivé de CCSDS RASDS, RM-ODP, ISO 10746 et conforme à IEEE 1471 .
Cet "ensemble de vues", comme décrit ci-dessous, est une liste de points de vue de modélisation possibles. Toutes ces vues ne peuvent pas être utilisées pour un projet donné et d’autres vues peuvent être définies si nécessaire. Notez que pour certaines analyses, les éléments de plusieurs points de vue peuvent être combinés dans une nouvelle vue, éventuellement en utilisant une représentation en couches.
Dans une dernière présentation, cet ensemble nominal de vues a été présenté comme une dérivation de modèle d'information sémantique RASDS étendu. Par la présente, RASDS signifie Architecture de référence pour les systèmes de données spatiales. voir la deuxième image.
- Point de vue d'entreprise
- Vue Organisation - Inclut les éléments organisationnels et leurs structures et relations. Peut inclure des accords, des contrats, des politiques et des interactions organisationnelles.
- Vue des exigences - Décrit les exigences , les buts et les objectifs qui guident le système. Dit ce que le système doit être capable de faire.
- Vue de scénario - Décrit la manière dont le système est censé être utilisé, voir planification de scénario . Comprend des vues utilisateur et des descriptions de la façon dont le système est censé se comporter.
- Point de vue information
- Vue métamodèle - Une vue abstraite qui définit les éléments du modèle d'information ainsi que leurs structures et relations. Définit les classes de données créées et gérées par le système et l'architecture de données.
- Vue Information - Décrit les données et informations réelles telles qu'elles sont réalisées et manipulées dans le système. Les éléments de données sont définis par la vue de métamodèle et ils sont référencés par des objets fonctionnels dans d'autres vues.
- Point de vue fonctionnel
- Vue de flux de données fonctionnel - Une vue abstraite qui décrit les éléments fonctionnels du système, leurs interactions, leur comportement, les services fournis, les contraintes et les flux de données entre eux. Définit les fonctions que le système est capable d'exécuter, quelle que soit la manière dont ces fonctions sont réellement mises en œuvre.
- Vue Contrôle fonctionnel - Décrit les flux de contrôle et les interactions entre les éléments fonctionnels du système. Comprend les interactions de contrôle du système global, les interactions entre les éléments de contrôle et les éléments capteurs / effecteurs et les interactions de gestion.
- Point de vue physique
- Vue Système de données - Décrit les instruments, les ordinateurs et les composants de stockage de données, leurs attributs de système de données et les connecteurs de communication (bus, réseaux, liaisons point à point) qui sont utilisés dans le système.
- Vue Telecomm - Décrit les composants telecomm (antenne, émetteur-récepteur), leurs attributs et leurs connecteurs (RF ou liaisons optiques).
- Vue de navigation - Décrit le mouvement des principaux éléments du système (trajectoire, chemin, orbite), y compris leur interaction avec les éléments externes et les forces qui sont hors du contrôle du système, mais qui doivent être modélisées avec lui pour comprendre le comportement du système (planètes, astéroïdes, pression solaire, gravité)
- Vue structurelle - Décrit les composants structurels du système (bus s / c, entretoises, panneaux, articulation), leurs attributs physiques et connecteurs, ainsi que les aspects structurels pertinents des autres composants (masse, rigidité, fixation)
- Vue thermique - Décrit les composants thermiques actifs et passifs du système (radiateurs, refroidisseurs, évents) et leurs connecteurs (rayonnement physique et espace libre) et leurs attributs, ainsi que les propriétés thermiques des autres composants (c.-à-d. L'antenne comme pare-soleil)
- Vue de puissance - Décrit les composants de puissance actifs et passifs du système (panneaux solaires, batteries, RTG) dans le système et leurs connecteurs, ainsi que les propriétés de puissance d'autres composants (système de données et éléments de propulsion comme puits de puissance et panneaux structurels comme mise à la terre avion)
- Vue Propulsion - Décrit les composants de propulsion actifs et passifs du système (propulseurs, gyroscopes, moteurs, roues) dans le système et leurs connecteurs, ainsi que les propriétés propulsives des autres composants
- Point de vue de l'ingénierie
- Vue d'allocation - Décrit l'allocation d'objets fonctionnels aux composants physiques et informatiques du système, permet l'analyse des performances et sert à vérifier la satisfaction des exigences
- Vue logicielle - Décrit les aspects d'ingénierie logicielle du système, la conception logicielle et la mise en œuvre de fonctionnalités dans les composants logiciels, sélectionne les langages et les bibliothèques à utiliser, définit les API, fait l'ingénierie d'objets fonctionnels abstraits en éléments logiciels tangibles. Certains éléments fonctionnels, décrits à l'aide d'un langage logiciel, peuvent en fait être implémentés sous forme de matériel (FPGA, ASIC)
- Vues matérielles - Décrit les aspects d'ingénierie matérielle du système, la conception matérielle, la sélection et la mise en œuvre de tous les composants physiques à assembler dans le système. Il peut y avoir plusieurs de ces points de vue, chacun spécifique à une discipline d'ingénierie différente.
- Vue Protocole de communication - Décrit la conception de bout en bout des protocoles de communication et des services de transport et de gestion de données associés, montre les piles de protocoles telles qu'elles sont implémentées sur chacun des composants physiques du système.
- Vue des risques - Décrit les risques associés à la conception du système, aux processus et aux technologies, attribue des attributs d'évaluation des risques supplémentaires à d'autres éléments décrits dans l'architecture
- Vue Control Engineering - Analyse le système du point de vue de sa contrôlabilité, allocation des éléments dans le système sous contrôle et système de contrôle
- Vue Intégration et Test - Examine le système du point de vue de ce qui doit être fait pour assembler, intégrer et tester le système et les sous-systèmes, et les assemblages. Comprend la vérification de la fonctionnalité appropriée, guidée par des scénarios, pour répondre aux exigences.
- Vue IV&V - validation indépendante et vérification de la fonctionnalité et du bon fonctionnement du système conformément aux exigences. Le système tel qu'il a été conçu et développé répond-il aux buts et objectifs?
- Point de vue technologique
- Vue des normes - Définit les normes à adopter lors de la conception du système (par exemple, protocoles de communication, tolérance aux rayonnements, brasage). Ce sont essentiellement des contraintes sur les processus de conception et de mise en œuvre.
- Vue Infrastructure - Définit les éléments de l'infrastructure qui doivent prendre en charge le processus d'ingénierie, de conception et de fabrication. Peut inclure des éléments de système de données (référentiels de conception, cadres, outils, réseaux) et des éléments matériels (fabrication de puces, installation de vide thermique, atelier d'usinage, laboratoire de test RF)
- Vue Développement et évaluation de la technologie - Comprend une description des programmes de développement de la technologie conçus pour produire des algorithmes ou des composants pouvant être inclus dans un projet de développement de système. Comprend l'évaluation des propriétés des composants matériels et logiciels sélectionnés afin de déterminer s'ils sont à un état de maturité suffisant pour être adoptés pour la mission en cours de conception.
Contrairement aux modèles de vues listés précédemment, cet «ensemble nominal de vues» répertorie toute une gamme de vues, permettant de développer des approches puissantes et extensibles pour décrire une classe générale d'architectures système intensives en logiciels.
Voir également
- Cadre d'architecture d'entreprise
- Architecture organisationnelle
- Méthodologie de développement logiciel
- Cadre d'architecture d'entreprise de trésorerie
- TOGAF
- Cadre Zachman
- Ontologie (science de l'information)
- Acquisition de connaissances
Les références
- Attribution
Cet article incorpore du matériel du domaine public du site Web de l' Institut national des normes et de la technologie https://www.nist.gov .
Liens externes
-
Médias liés aux modèles View sur Wikimedia Commons
