第2章計算論的思考と設計の再利用性
2.3 Evolving Architectures into Useable Products2.3 アーキテクチャーを使える製品へと発展させる
Learning Objectives学習目標
By the end of this section, you will be able to:
この節を終えると、次のことができるようになる。
• Analyze similarities between architectures and apply patterns
• アーキテクチャー同士の類似点を分析し、パターンを適用する。
• Discuss how to accelerate the creation of applications
• アプリケーションの作成を加速する方法を論じる。
The combination of top-down, adaptive design reuse, and bottom-up, computational thinking, optimizes modern software development. This blend allows software developers to find a middle ground by adapting and assembling existing components, minimizing the need for developing entirely new software. A clear example of this cooperation is evident in modern websites, where the Model-View-Controller architectural pattern is widely employed. The Model-View-Controller (MVC) is a software architectural pattern commonly used in the design of interactive applications, providing a systematic way to organize and structure code. The pattern separates an application into three interconnected components: model, view, and controller. The model represents the application’s data structure and business logic, managing data and rules. The view is responsible for displaying the user interface; it shows data to the user and sends user commands to the controller. The controller serves as an intermediary between the model and the view. It processes user input received from the view, interacts with the model to retrieve or update data, and determines the appropriate view for presenting the response. Many practical web application frameworks, such as Django, have already implemented the MVC pattern. In this setup, the application is divided into three parts: the model handles the data structure, the view displays the data on web pages, and the controller manages the business logic, facilitating interaction between the model and the view. Adding a broker pattern to MVC architectures can improve the system’s scalability and flexibility when applicable and/or necessary. The broker acts as a middleman that manages communication between different parts of the application, helping to handle more data and complex operations efficiently.
英語のヒント
トップダウンの適応的な設計の再利用と、ボトムアップの計算論的思考を組み合わせることで、現代のソフトウェア開発を最適化できる。開発者は、既存の部品を調整して組み立てるという中間の方法を見いだし、ソフトウェアを全面的に新規開発する必要を最小限に抑えられる。この連携がよく見える例が、モデル・ビュー・コントローラーというアーキテクチャーパターンを広く使う、現代のウェブサイトである。モデル・ビュー・コントローラー（MVC）は、対話型アプリケーションの設計でよく使う、ソフトウェアのアーキテクチャーパターンであり、コードを体系的に整理・構造化する方法を提供する。アプリケーションを、互いに結びついたモデル、ビュー、コントローラーの三つに分ける。モデルは、アプリケーションのデータ構造と業務上の論理を表し、データと規則を管理する。ビューはユーザーインターフェースの表示を担当し、利用者へデータを見せ、利用者の命令をコントローラーへ送る。コントローラーはモデルとビューの仲介役となる。ビューから受け取った入力を処理し、モデルとやり取りしてデータを取得・更新し、応答を示す適切なビューを決める。Djangoなど、多くの実用的なウェブアプリケーションフレームワークには、MVCパターンがすでに実装されている。この構成では、モデルがデータ構造を扱い、ビューがウェブページにデータを表示し、コントローラーがビジネスロジックを管理して両者のやり取りを助ける。適用可能な場合や必要な場合には、MVCアーキテクチャーにブローカーパターンを加えることで、システムの拡張性と柔軟性を高められる。ブローカーは、アプリケーションの異なる部分の間の通信を管理する仲介役として働き、より多くのデータや複雑な処理を効率よく扱えるようにする。
Leveraging these existing frameworks enables developers to concentrate on crafting the specific logic relevant to the website rather than reinventing the wheel. The beauty of this approach lies in the ability to swiftly piece together solutions by extending and adapting the available frameworks. By doing so, developers streamline the development process, enhance efficiency, and capitalize on the collective wisdom embedded in proven frameworks, thereby fostering innovation in a more focused and resource-efficient manner.
英語のヒント
既存のフレームワークを使うと、開発者は車輪を再発明することなく、そのウェブサイトに固有のロジックを作ることへ集中できる。この方法の優れた点は、利用できるフレームワークを拡張・調整し、解決策を素早く組み立てられることである。こうして開発の過程を円滑にし、効率を高め、実績のあるフレームワークに組み込まれた集合的な知恵を活用することで、目的を絞り、資源を有効に使いながらイノベーションを促せる。
Leveraging Architectural Similarities and Applying Patternsアーキテクチャーの類似点の活用とパターンの適用
The adaptive design reuse approach is a strategy in software development that emphasizes the efficient reuse of existing design solutions to create new systems or applications. The beauty of the adaptive design reuse approach is that the business solution architecture model helps create abstract representations of real systems. Therefore, if there exist tangible realizations of the various components that are part of these abstract representations, it is possible to implement the model and create specialized running business solutions from it.
英語のヒント
適応的な設計の再利用は、新しいシステムやアプリケーションを作る際に、既存の設計による解決策を効率よく再利用することを重視する、ソフトウェア開発の戦略である。その優れた点は、ビジネスソリューションのアーキテクチャーモデルが、現実のシステムの抽象的な表現を作るのに役立つことである。そのため、抽象表現を構成する各部品の具体的な実体があれば、モデルを実装し、特定の用途に適した、実際に動くビジネスソリューションを作れる。
A solutions continuum is a strategy where existing solutions, components, or patterns are leveraged and adapted for use in different contexts. Figure 2.24 illustrates the TOGAF model of reuse that is referred to as the solutions continuum. As mentioned earlier, TOGAF does not provide a prescriptive approach to creating and/or managing a catalog of patterns. However, various pattern repositories are available on the Internet and the adaptive design technique can be used to avoid having to reinvent the wheel when architectural patterns and related component implementations exist and can be customized and assembled with new components. More information on this topic is provided in Chapter 10 Enterprise and Solution Architectures Management.
英語のヒント
ソリューションコンティニュアムとは、既存の解決策、部品、パターンを活用し、異なる状況に適応させる戦略である。図2.24に、ソリューションコンティニュアムと呼ばれるTOGAFの再利用モデルを示す。先に述べたように、TOGAFはパターンカタログの作成・管理方法を具体的に規定していない。しかし、インターネット上にはさまざまなパターンの保管場所がある。アーキテクチャーパターンと、それに関わる部品の実装が存在し、調整して新しい部品と組み合わせられるなら、適応的な設計の技法で、一から作り直す手間を避けられる。この話題については、第10章「エンタープライズアーキテクチャーとソリューションアーキテクチャーの管理」で詳しく説明する。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 2.24 This TOGAF solutions continuum illustrates how each architecture guides and supports the others. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図2.24 TOGAFのソリューションコンティニュアムは、それぞれのアーキテクチャーがほかのものをどう導き、支えるかを示す。（出典：著作権Rice University、OpenStax。CC BY 4.0ライセンス）
As illustrated in Figure 2.25, the TOGAF solutions continuum offers a limited set of dimensions. It serves as a guideline, and The Open Group allows interested parties to enhance the model by incorporating additional dimensions that are relevant to their specific needs.
英語のヒント
図2.25のように、TOGAFのソリューションコンティニュアムが示す分類軸は限られている。これは指針としての役割を果たすものであり、The Open Groupは、関心を持つ人々が固有のニーズに関係する軸を加えて、モデルを充実させることを認めている。
attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license · CC BY 4.0 · Source出典
Figure 2.25 The TOGAF architecture continuum can suggest extensions but may only be able to focus on one aspect at a time. (attribution: Copyright Rice University, OpenStax, under CC BY 4.0 license)
図2.25 TOGAFのアーキテクチャーコンティニュアムは拡張を示唆できるが、一度に一つの側面にしか注目できない場合がある。（出典：著作権Rice University、OpenStax。CC BY 4.0ライセンス）