学習メモその３：UML モデリングのエッセンス 第2版
見出しの画像はUMLの公式ロゴです。
メモの経緯
今回は第2章：開発プロセスの概要 2.1プロセスの外観から〜2.4構築フェーズの計画です。
メモ
フレームワーク
In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, toolsets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.
コンピュータプログラミングにおいて、ソフトウェアフレームワークは、汎用的な機能を提供するソフトウェアが、ユーザーが書いた追加コードによって選択的に変更され、それによってアプリケーション固有のソフトウェアを提供できる抽象化されたものである。アプリケーションを構築し配備する標準的な方法を提供し、ソフトウェアアプリケーション、製品、およびソリューションの開発を容易にするため、より大きなソフトウェアプラットフォームの一部として特定の機能を提供する普遍的で再利用可能なソフトウェア環境である。ソフトウェアフレームワークには、サポートプログラム、コンパイラ、コードライブラリ、ツールセット、アプリケーションプログラミングインターフェース（API）などが含まれ、プロジェクトやシステムの開発を可能にするためにすべての異なるコンポーネントをまとめている場合があります。
モデル
A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper.
モデルとは、ソフトウェア開発において、高層ビルを建てるときの設計図や図面（敷地図、立面図、物理モデル）のような役割を果たすものです。
方向づけ(inception)
初め、発端
The primary goal of the Inception phase is to establish the case for the viability of the proposed system.
インセプションフェーズの主な目的は、提案するシステムの実現可能性を立証することです。
ドメインモデル
In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data. In ontology engineering, a domain model is a formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules, typically grounded in a description logic.
ソフトウェア工学において、ドメインモデルとは、動作とデータの両方を組み込んだドメインの概念モデルである。オントロジー工学では、ドメインモデルとは、概念、役割、データ型、個体、ルールを備えた知識ドメインの形式的な表現であり、一般に記述論理に基づくものである。
プロトタイプ
A prototype is an early sample, model, or release of a product built to test a concept or process. It is a term used in a variety of contexts, including semantics, design, electronics, and software programming. A prototype is generally used to evaluate a new design to enhance precision by system analysts and users. Prototyping serves to provide specifications for a real, working system rather than a theoretical one. In some design workflow models, creating a prototype (a process sometimes called materialization) is the step between the formalization and the evaluation of an idea.
プロトタイプとは、コンセプトやプロセスをテストするために作られた製品の初期サンプル、モデル、またはリリースを指します。この用語は、意味論、デザイン、エレクトロニクス、ソフトウェアプログラミングなど、さまざまな文脈で使用されています。プロトタイプは一般的に、システムアナリストやユーザーによる精度を高めるために、新しい設計を評価するために使用されます。プロトタイプは、理論的なものでなく、実際に動くシステムの仕様を提供する役割を果たす。設計ワークフローモデルでは、プロトタイプの作成（マテリアライゼーションと呼ばれることもある）は、アイデアの形式化と評価の間のステップである。
コンポーネント
A component in the Unified Modeling Language represents a modular part of a system that encapsulates the state and behavior of a number of classifiers. Its behavior is defined in terms of provided and required interfaces, is self-contained, and substitutable. A number of UML standard stereotypes exist that apply to components.
統一モデリング言語のコンポーネントは、多くの分類器の状態と動作をカプセル化するシステムのモジュラー部分を表します。その動作は、提供されたインターフェイスと必要なインターフェイスの観点から定義され、自己完結型で置き換え可能です。コンポーネントに適用されるUML標準ステレオタイプが多数存在します。
アーキテクチャ
Large enterprise applications - the ones that execute core business applications, and keep a company going - must be more than just a bunch of code modules. They must be structured in a way that enables scalability, security, and robust execution under stressful conditions, and their structure - frequently referred to as their architecture - must be defined clearly enough that maintenance programmers can (quickly!) find and fix a bug that shows up long after the original authors have moved on to other projects. That is, these programs must be designed to work perfectly in many areas, and business functionality is not the only one (although it certainly is the essential core). Of course a well-designed architecture benefits any program, and not just the largest ones as we've singled out here.
大規模なエンタープライズアプリケーション（中核的なビジネスアプリケーションを実行し、企業を存続させるもの）は、単なるコードモジュールの束であってはなりません。スケーラビリティ、セキュリティ、そしてストレスの多い状況下での堅牢な実行を可能にする方法で構造化されていなければなりません。そして、その構造（しばしばアーキテクチャと呼ばれる）は、元の作者が他のプロジェクトに移ってしまった後でも、保守プログラマーがバグを見つけて修正できるように、明確に定義されていなければなりません。
コミットメント
委託、委任、引き渡し、投獄、拘留、委員会付託、言質(げんち)、約束、公約、責任
最後までお読みいただきありがとうございます。
この記事が気に入ったらサポートをしてみませんか？