安全性信頼性の設計

1.フェールセーフ

故障が発生しても安全である

2.フールプルーフ

誤操作をしても大丈夫

3.フォールトトレランス

システムの一部に問題が発生しても、全体が停止することは、ない

4.フェールセーフ

故障が発生した場所を切り離して、最低限のシステムの稼働を続ける

5.フォールバック

障害が発生した時に、性能を落としたりh代替手段を用意する

Model - View -* Design Patterns

公開されている

Model - View -* Design Patterns

のキモ部分を読んで、勉強してきたいと思います。

イントロ

すべてのMV*パターンは、関心の分離のアイディアに基づくもの。

ユーザインターフェースのデザインでは、

アプリケーションのドメインモデルと、ユーザインターフェースを

2つの層に分けるもの。

MV*デザインパターンのシリーズの違いは、ユーザインターフェースと

アプリケーションのドメインの構造や同期方法が異なる。

MV*デザインパターンは、Mは、モデル、Vは、Viewを表し

*は、MとVのコミュニケーションの方法を表す。

Widget-base User Interface(Forms)

ユーザインターフェースを構成するwidgetを、Formに配置して、

ハンドルするロジックも、Formへ入れる。

ドメインとUIは、分離されておらず、保守も難しい。

しかし、以下のようなメリットもある。

〇 シンプル

シンプルで理解しやすい

〇 一貫性

基本的に同期処理で理解しやすい

〇 効率がよい

レイヤーがない分、効率が良い

MVC(Smalltalk'80 MVC)

意図

アプリケーションドメインとその表現を3つのモジュールに分け、

それぞれ特定の処理をさせる。

「データのストレージとマネジメント」

「データの表示」

「ユーザの入力のハンドリング」へ分割する。

構造

Smalltalk'80MVCでは、Modelコンポーネントは、ドメインのデータやロジックを表す。

Modelコンポーネントから他のコンポーネントへの参照はない。

Viewコンポーネントは、Modelデータの表示を行う。

Controllerは、ユーザのインプットをハンドルする。

ViewとControllerは、組になって動く。

例えば、Viewが入力エリアを表示し、ユーザがテキストを入力しエンターを押すと、

Controllerがそれをハンドリングする。

Model-Ciew-Controllerの共同

例えば、ユーザがテキストボックスの値を変更すると、ControllerはModelにそれを伝え、

Modelが変更される。値が変更されると、Modelは値が変更されたことを通知する。

通知を受け取ったViewは、新しい値を読み取り、それを表示する。

結果

Smalltalk'80MVCの分割方法は、効果的であることがわかった。

関心を分離することで、プレゼンテーションのロジックへ影響を与えず、

ドメインモデルを変更することができるし、アプリケーションのロジックに

影響を与えることなく、複数のUIを提供することができる。

Web MVC

意図

Webアプリケーションで、ドメインのロジックとプレゼンテーションのロジックを

分離する。

Model ・・・データのストア

Controller ・・・ユーザのアクションのハンドリング

View ・・・HTMLのレイアウト

動機

Smalltalk'80 のMVCとは異なり、WebMVCは、以下のようになる。

アプリケーションのロジックは、Controllerから起動される。

モデルは、Viewで必要なデータを保管するのみ。Modelは、ドメインのエンティティ

でもよい。Controllerは、ユーザのインプットをハンドリングし、レタリングのための

モデルを生成する。Controllerは、アプリケーションのドメインロジックへ

アクセスする。

協同

サーバがリクエストを受け取ると、アドレスへ対応したコントローラーが起動される。

コントローラーは、ビジネスドメインへアクセスして、データを取得する。

コントローラーは、モデルをインスタンス化して、取得したデータで初期化する。

そのデータは、Viewに渡される。Viewは、ページを生成する。

MVVM Model-View-View Model

MVCモデルの問題の1つに、ドメインモデルではない、View State を

管理する必要があることがある。

これを解消するために、Model-View-View Moel あるいは、

Model-View-Presentarion Model が考え出された。

Presentarion Model あるいは、View Moel は、

ドメインモデルのラッパーとなる。

ドメインモデルが、ドメインのオジュタイを管理し、

Presentarion Model が、View Stateを管理する。

また、Presentarion Model は、Domain Modelに含まれない

ロジックを管理する。

MVVMのViewは、Presentarion Model を参照し、直接Domain Model

を参照することはない。MVCモデルにおけるviewとControllerのペアは、

別のコンポーネントと考えず、単一のviewのコンポーネントとなる。

Application Model

意図

domain logic から、次の4つの責務を持つPresentation logicを切り離す。

(1) データのストアとマネジメント

(2)データの表示

(3)ユーザの入力制御

(4)view stateのハンドリング

Domain dataとview stateは、分離する。

動機

MVCモデルでは、view stateが扱いずらい。また、modelにsubmitされる前に

入力を制御する機能を提供する。

構造

Application Modelは、Smalltalk'80 MVCパターンの基本的な構造を継承している。

Modelは、ドメインデータを管理し、Viewがデータを表示する。

Controllerが、ユーザの入力をハンドリングする。

ViewとControllerは、Modelを直接扱うことはない。

代わりに、このパターンでは、Application Modelという

中間的なコンポーネントを導入する。

View、Controller --> Application Model --> Model 

Application Modelは、view stateを管理し、ユーザの入力をModelへ反映する前の

プロセスを提供する。

協業

Application Modelは、MVCを拡張したものであるため、考え方は同じである。

ViewとControleerは、ドメインデータをラッピングしたApplication Modelを扱う。

Application Modelは、データが変化した際、それをviewへ通知する。

また、Model dataを更新する。

Model dataの管理するデータに対して、Application Dataでは、そのデータの

表示色を保持するなど。

結論

Application Modelは、Smalltalk'80 MVCパターンの欠点を尾久なうもの。

Application Modelは、view stateのハンドリングをシンプル化し、

ユーザのインプットをModelへ渡す前のロジックを扱う機能を提供する。

Microsoft MVVM

意図

ドメインロジックとプレゼンテーションロジックを分離する、モデルは

ドメインデータをハンドリングし、ViewModelは、view stateとユーザインタラクション

を行う。Viewは、UI。

動機

Microsoft MVVMでは、ViewModelを持つことができる。

ViewModelは、複数のVIewへ対応することもできる。

これを使えば、同じデータを異なる方法で表示できる。

構造

線形の構造をしている。Viewは、ユーザーインターフェースの

レンダリングを行う。

Viewは、View Modelを利用して、必要な場合に通知などを行う。

Viewは、View Modelに対して一方向の参照である。

View Modelのプロパティが変更されると、Viewに通知される。

Viewが提供するUIの変更は、View Modelのプロパティがダイレクトに

変更される。

View Modelは、view stateやユーザとのインタラクションを管理する。

Domainモデルにアクセスして、ドメインデータを利用する。

また、ビジネスロジックを起動する。

View ModelからViewは参照しない。

協同

ViewModelは、Modelに直接アクセスしてドメインデータを利用する。

ViewModelは、Modelをつかって、ロジックやデータアクセスなどの

Actionを起動することができる。


MVP : Model - View - Presenter

MVPのいろいろなパターンは、MV*パターンを改良したもの。

Dolphin Smalltalk MVP 

意図

ドメインロジックとプレゼンテーションロジックを厳密に分離したもの。

Modelは、ドメインデータをハンドリングし、Viewは、入力関連機能、

UIはレンタリング機能、Presenterが、ViewとModelの同期をとる。

構成

Modelのは、純粋にドメインデータを扱う。

データの変更に関して、通知する機能を持つ。

Viewは、UIを描画する。

また、ユーザのインプットをハンドリングする。

ユーザの入力に対するActionは、Presenterを直接呼ぶことによって

委譲する。Presenterは、ユーザのインプットをハンドリングし、

ドメインのロジックを起動し、Modelのデータの一貫性を保ち、

必要に応じて、Viewへ追加ロジックを提供する。

Javaの練習 浮動小数点数の演算

1. 文法など 

 浮動小数点数の演算をする場合は 

 BigDecimal

を利用する。

2.サンプル

import java.math.BigDecimal ;

public class Main {

    public static void main(String[] args) {

      var  bd1 = new BigDecimal("0.2") ;

      var  bd2 = new BigDecimal("0.5") ;

      var  bd3 = new BigDecimal("1.0") ;

      // bd1*bd2 の値と、bd3の値を比較する。

        System.out.println(bd1.multiply(bd2).compareTo(bd3));

    }

}

3.実行結果

0

が、表示されます。

bd1.multiply(bd2)で、1.0

compareToで、1.0と比較します。

compareToは、以下の値を返します。

引数の方が大きい場合は、1

引数の方が小さい場合は、-1

同じ場合は、0

Spring プログラムの分割例

・Controller 

    処理の流れを制御する。リクエストを受け取り、業務ロジックを呼び出し、

　Viewを返す。

・View

   動的にHTMLを生成する。

・Service

     業務ロジックを実装する。

・Repository

     データベースとのデータのやり取りを実行する。

・次のような処理の流れとなる。

リクエスト --> Controller --> Service -->Repository

Repository-->Service -->Controller-->View-->レスポンス