Accueil
 > Rapports de TEC > Blogue de TEC > Information Systems Architecture-centrée dans le domaine ...

Information Systems Architecture-centrée dans le domaine de la fabrication - Partie II - Le processus d'architecture

Écrit par : Glen B. Alleman
Date de publication : juillet 18 2013

Glen         B. Alleman est associée à Niwot Ridge Consulting, www.niwotridge.com

propos de ce Remarque:

Cette         la note est présentée en cinq parties comme suit:

  1. Présentation           à l'Architecture Software

  2. L'architecture           Processus

  3. étapes           dans l'architecture Process

  4. Déménagement           De la planification à la mise en œuvre

  5. Application           la méthodologie

partie         II - Le processus d'architecture

        Le choix d'une méthodologie spécifique pour la capture, la définition et la description         l'architecture du système est une décision arbitraire. La méthodologie suivante         est utilisé comme un exemple. D'autres méthodes peuvent être utilisées tant ils une         fournir un ensemble assez riche d'artefacts nécessaires pour articuler la         les exigences et les solutions qui répondent à ces exigences

Figure         1 décrit le processus par lequel l'architecture du système est découvert,         vérifiée, et déployé.

Cette         méthodologie fournit un large cadre dans lequel l'architecture des systèmes peut         être mis au travail. Selon les besoins spécifiques de l'organisation, chaque         phase de méthodologie peut être adaptée au résultat souhaité. Dans certaines situations,         l'analyse de rentabilisation et Stratégie informatique existent déjà et les aspects techniques         du système dominer l'effort. Dans d'autres situations, le cadre         pour réfléchir sur le problème doit d'abord être construit avant toute réelle         la construction du système peut avoir lieu.

L'         méthodologie fournit des lignes directrices sans trop contraindre la solution         domaine. La méthodologie est fournisseur neutre, la notation neutre et adaptative         aux besoins à court et à long terme de l'organisation. La méthodologie a été         preuves sur le terrain, dans une grande variété d'environnements de l'industrie manufacturière.

Figure         1. La méthodologie étapes

src="/NavExp/media/TEC_Articles/GA_EV_GBA_09_06_02_1-1a.gif"

        Méthodologie et 4 +1

        Les principales composantes de la méthodologie qui sont axées sur l'architecture 4 +1         Description sont présentés dans la figure 3. Cette méthodologie est déployé dans le         contexte de:

Commercial         hors les produits (COTS) intégrés dans un système fédéré. Le         fonctionnalité externe d'un produit COTS est défini par le vendeur. Le         comportement du système est généralement fixé en quelque sorte, avec peu ou pas         possibilité de modifier le fonctionnement interne. Comportements externes peuvent parfois         être adaptés aux besoins de l'entreprise, dans le cadre du produit COTS.

ligne         des bases de données d'entreprises utilisés pour séparer les données des applications.         Les applications héritées détiennent des renseignements sur leur territoire qui doit         être intégré au nouveau système. Dans de nombreux cas, il n'est pas possible         pour déplacer ces données existantes vers un nouveau système.

workflow         moteurs utilisés pour gérer les processus d'affaires. Dans de nombreux environnements, le         les processus de travail sont fluides, changeant avec le climat des affaires. Adaptation         les processus de travail dans le processus de l'entreprise se fait habituellement par certains         sous forme de flux de travail.

aide         ce contexte, l'approche traditionnelle de développement de logiciels de système         architecture n'est pas approprié. Écriture du logiciel dans l'environnement COTS         est un événement rare. L'une architecture à 4 est adapté pour décrire la         attributs de pratiques comportementales et le meilleur du système. Dans le domaine de COTS,         4 +1 descriptions d'architecture sont maintenant:

logique         - Les exigences fonctionnelles du processus d'entreprise qui sont directement         mise en oeuvre par le système. Il s'agit notamment des processus manuels ou personnalisés         composants qui doivent être fournis pour contourner les lacunes dans le système COTS.

processus         -. Les capacités du système qui sont nécessaires pour répondre aux besoins de l'entreprise

développement         - Le fournisseur, intégrateur de systèmes, processus d'affaires, et les équipes de gestion         et les ressources nécessaires pour définir, acquérir, installer, déployer et exploiter         le système.

physique         - L'infrastructure nécessaire pour définir, acquérir, installer, déployer et exploiter         le système.

Scénarios         - Les cas d'utilisation qui décrivent la séquence d'actions entre le système         et de son environnement ou entre les objets extérieurs impliqués dans un particulier         exécution du système.

L'         conception de systèmes logiciels implique un certain nombre de disciplines appliquées au cours de         les différentes phases de la méthodologie. Dans le passé, la décomposition fonctionnelle         et la modélisation des données était le mécanisme accepté pour définir l'architecture du système.         L'aspect descriptif et générative de ces notations a cédé la place         de notations basées sur UML. [7] Bien que la méthodologie décrite ici est         techniquement indépendant de toute notation ou les exigences de style de la méthodologie,         il ya des avantages à utiliser les outils state-of-the-art actuel.

Ces         suivants:

  • Fournir           rassurer par des descriptions graphiques du système. En utilisant une couche           langage descriptif, des photos du système peut être construit à tous           niveaux de détail - à partir de diagrammes de cadres de haut niveau à programmeur de           Détails de niveau de données et des processus.

  • Fournir           descriptions générateurs qui transforment décompositions fonctionnelles dans           des modèles de code.

  • forte           descriptions textuelles, depuis images seules sont rarement suffisantes pour           transmettre le sens du design.

  • esthétique           interprétations qui véhiculent des bons principes de conception grâce à un simple, clair,           et la notation concise.

Notes

[7] Le Unified         Modeling Language (UML) est un langage formel utilisé pour capturer la sémantique         (Connaissance) d'un sujet et d'exprimer cette connaissance aux autres, y compris         machines. Les aspects de modélisation d'UML concentrer sur la compréhension d'un sujet         et recueillir et diffuser les connaissances sur le sujet. L'unification         aspects d'UML viennent sur les meilleurs pratiques de l'industrie,         principes, les techniques, méthodes et outils. Bien que UML est orienté objet         il peut être utilisé dans une variété de paramètres du logiciel et du système à l'aide de l'         définition d'architectures de systèmes [Alhi98], [Mull97].

Méthodologie         et l'architecture

        La figure 2 présente une topologie réarrangé pour la méthodologie. Cet arrangement         met l'accent sur l'application des principes de l'architecture des composants de         la méthodologie. Il ya des étapes dans la méthodologie qui ne sont pas abordées         dans la figure 2. Bien que ces étapes peuvent être touchés par l'architecture qu'ils         sont secondaires à l'analyse des besoins, la conception du système technique, système         Déploiement Développement et Système.

Figure         2. Les détails de la méthodologie et de sa relation à l'architecture du système.

src="/NavExp/media/TEC_Articles/GA_EV_GBA_09_06_02_1-2a.gif"

Méthodologie         pour le SRA

        Le requise Système d'Analyse (SRA) comprend la découverte de la fonctionnelle         et les exigences non-fonctionnelles qui influent sur l'architecture de l'         système. Ces exigences s'ajoutent à la transformation de l'entreprise         exigences du système [Somm97]:

fonctionnelle         exigences - des exigences pour le système qui peut être déclaré         comme des comportements spécifiques. Les exigences suivantes sont pour le fonctionnel         Architecture pas le processus d'affaires fourni par cette architecture fonctionnelle.

  • Abstraction           - Permet une réduction de la complexité.

  • Encapsulation           - Traite de regroupement des abstractions.

  • information           cacher - recèle plus de détails.

  • modularisation           - Fournit une décomposition significative.

  • séparation           - Assure la séparation de collaborer composants.

  • Coupling           / Cohésion - sont des mesures de la structure du système.

  • suffisance,           l'exhaustivité et la primitivité - sont les propriétés des composants.           

  • séparation           de la politique et de la mise en œuvre - données et processus sont isolés.

  • séparation           de l'interface et la mise en œuvre - Interfaces utilisateur et le noyau des processus           sont isolés.

  • simple           références ponctuelles - l'intégrité référentielle est maintenue.

  • Diviser           et conquérir des stratégies - architecture modulaire.

non fonctionnel         exigences - sont généralement appelés les capacités du système et représentent         un ensemble d'attributs du logiciel et du matériel qui peut être mesurée.         Il s'agit notamment de:

  • Fiabilité           - La robustesse du système en présence de fautes.

  • évolutivité           - La capacité d'augmenter la performance du système avec peu ou pas           impact sur l'architecture du système.

  • Disponibilité           -. La capacité à fournir des services lorsqu'ils sont appelés à le faire

  • maintenabilité           - La capacité de réparer le logiciel ou le matériel sans impact sur le           la disponibilité de système.

  • Performance           - La capacité d'offrir des services dans les attentes des utilisateurs.           

  • Réparabilité           - La capacité de réparer le système sans causer de dommages indirects.           

  • Évolutivité           - La capacité à apporter des modifications au matériel et les composants logiciels           sans influencer la disponibilité.

Méthodologie         pour le TSD

        La conception du système technique (DNT) développe une description détaillée de la         système en fonction des points de vue multiples. Chacun des points de vue est un raffinement         de la fonctionnalité des produits COTS posé sur les processus d'affaires.

Enterprise         vue - décrit la portée et les politiques des systèmes d'entreprise à travers         l'entreprise. Ce point de vue tient compte de tous les utilisateurs du système dans un         tenter de normaliser les exigences de sorte que toute une série d'exigences ou         utilisateur ne domine pas l'architecture du système. Ce point de vue se fonde sur         fournissant un système qui est considéré comme l'infrastructure.

information         vue - décrit la sémantique (le sens) de l'information et         le traitement de l'information. Cela suppose l'information est isolé         du traitement et que les activités de transformation vont changer au fil         temps, tandis que la sémantique de l'information reste statique dans toute         le cycle de vie du système.

Computational         voir - décrit la décomposition fonctionnelle du système. Cette         vue décompose le système en unités de calcul et reconstruit l'         système d'une manière qui prend en charge la meilleure organisation fonctionnelle du         système.

Ingénierie         voir - décrit l'infrastructure du système vu de l'         composants physiques, des réseaux, des serveurs, des périphériques et des postes de travail.

Technology         vue - décrit les choix technologiques qui doivent être prises lors de la sélection         fournisseurs pour l'infrastructure et de permettre aux composants COTS.

Conclusion         de la Partie II

        Ceci est la deuxième partie d'un billet de cinq partie. La partie suivante décrit les étapes         dans le processus de l'architecture.

        Auteur

Glen         B. Alleman, a fourni des services de consultation pour une variété d'industries         et les domaines d'activité dans les places de marché industriel et commercial. Ces         comprendre, les systèmes de commerce électronique, systèmes d'édition, les technologies de l'information         des stratégies, des systèmes de fabrication, les systèmes de conception technique et des logiciels         l'amélioration des processus.

Il         possède une expérience directe dans une variété d'environnements d'intégration à grande échelle         et les domaines d'affaires. Il possède également une vaste programme et de la gestion de projet         expérience avec de multiples projets simultanés impliquant des matériels, logiciels,         plusieurs sites et activités d'intégration de systèmes legacy.

M.         Alleman a une connaissance profonde technique et architectural d'une variété de         paradigmes du système, notamment: client / serveur, CORBA et les systèmes basés sur le Web

.       

Il         est le conseiller principal pour Niwot Ridge Consulting, Niwot, Colorado,         www.niwotridge.com.

Références         - Partie II

[Alhi98] UML             en bref:. Référence rapide Bureau SS Aihir, O'Reilly 1998
[Mull97] instantanée             UML, P.-A. Muller, WROX, 1997.
[Somm97]             Ingénierie d'un guide de bonnes pratiques, I. Someerville et P. Sawyer, John             Wiley & Sons, 1997.

 
comments powered by Disqus


©2014 Technology Evaluation Centers Inc. All rights reserved.