2025年11月30日日曜日

Java 型推論

 1.文法

ローカル変数を、var で宣言すると、型が推論されます。


2.サンプル

public class Main {

    public static void main(String[] args) throws Exception {

        //型推論

        var var1 = "Test" ; 

        //型を出力

        System.out.println(var1.getClass().getSimpleName()) ; 

    }

}


3.実行結果

String 

が出力されます。







Java JDKのバージョンの取得

 1. 文法など

System.getProperty("java.version")

を利用します。


2.サンプルコード


public class Main {

    public static void main(String[] args) throws Exception {

         System.out.println(System.getProperty("java.version"));

    }

}


3.実行結果

paiza.io( https://paiza.io/ja )で試してみると、

18.0.2

と表示されました。





ベームのスパイラルモデル

 ベームは、リスク・ドリブンのソフトウェア開発方法論、

スパイラルモデルを提唱した。

これは、リスクマネジメントとインクリメンタルな開発を統合したものである。


ソフトウェア開発は、らせん(スパイラル)のように進む。

らせんの1周が、ソフトウェア開発のフェーズにあたる。

最初のフェーズは、システムのフィージビリティスタディに関するものである。

次のフェーズは、要件定義、次のフェーズは、システム設計・・・

と進む。

スパイラルモデルは、変更に対して耐性がある。

スパイラルモデルのそれぞれのフェーズは、次の4つのセクターに分けられる。

1.目標の設定

このフェーズの目標を設定する。制約等に基づき、成果物が特定され、

詳細な計画が作られる。プロジェクトのリスクが特定され、

リスクに対応するための代替プランが作成される。


2.リスクアセスメントと、リスクの低減

プロジェクトのリスクを特定し、その分析や低減が行われる。

例えば、要求の不明瞭さに対しては、プロトタイプを開発するなど。


3.開発と検証


4.計画

プロジェクトのレビュに基づき、スパイラルの次のループを実行するかを、

決定する。


スパイラルモデルの、他のモデルとの違いは、明示的にリスクを認識すること、

である。

リスクが特定され、それに対する開発を実行した結果で、次のフェーズの

計画を作ることとなる。





2025年11月15日土曜日

MPAとSPA

 MPA

・Multi Page Application 

・リクエストのたびにブラウザとサーバの間の通信が発生する。


SPA

・Single Page Application

・最初にサーバからHTMLやJavaScriptをダウンロードし、

以降はJavaScriptでサーバと通信する。

画面全体の書き直しは、発生しない。




Struts2の動作

 Struts2は、MVCフレームワークである。

コントローラは、dispatch servletフィルターや、Interceptorとして実装される。

モデルは、Actionとして実装される。

ビューは、result typeとresultとして実装される。


struts2のrequestのライフサイクルは、以下である。

1. ユーザがrequestを送る。

2.Filter Dispacherが、requestを受け取り、適切なActionを決定する。

3.Configured Interceptorの機能で、validationやFile uploadなどが実行される。

4.選択されたActionが実行され、requestに対する処理が行われる。

5.必要に応じてConfigured Interceptorが、後処理を行う

6.結果が、ビューとして返される


Struts2のコアコンポーネントは、次である。

Action

それぞれのURLは、特定のActionにマッピングされる。

Actionは、ユーザからのリクエストに応じたロジックを処理する。

Actioには、他2つの重要な処理がある。

Actionは、requestの情報をViewから受け取る。

また、Viewの描画するデータを決定する。

Actionの結果によって、正常なViewやエラー処理のViewのように、

Viewが使い分けられる。


Interceptors

Interceptorは、actionから分離された処理を実行する。

Actionが実行される前後の処理、例外処理などに使われる。




2025年11月9日日曜日

クロニクル Tomcatでhello world

tomcat-10.1.48です。

1. ファイルの作成

tomcatのインストールディレクトリ/webapps

の下に

test

ディレクトリを作成します。

testディレクトリの下に、以下のような、helloworld.txt

を作成します。

hello world


2. 確認

tomatを起動し、ブラウザーで、

http://localhost:8080/test/helloworld.txt

を指定すると

hello world

が表示されます。




クロニクル MacでTomcat

 java 17.0.16 2025-07-15 LTS


がインストールされているとします。


1. ダウンロード


以下のサイト


https://tomcat.apache.org/download-10.cgi


から、


Core zip版をダウンロードします。


apache-tomcat-10.1.48.zip


がダウンロードしました。


2.展開


1.でダウンロードしたファイルを以下のコマンドで展開しました。


unzip apache-tomcat-10.1.48.zip


apache-tomcat-10.1.48フォルダーができました。


3.起動


apache-tomcat-10.1.48/binで


%chmod 775 startup.sh

%chmod 775 catalina.sh

% ./startup.sh


4.確認


ブラウザーで、


http://localhost:8080


を指定すると、


Apache Tomcat/10.1.48

If you're seeing this, you've successfully installed Tomcat. Congratulations!


画面が表示されました。


5.停止


% chmod 775 shutdown.sh

% ./shutdown.sh


で停止しました。



2025年11月3日月曜日

論文 SYSTEMS DEVELOPMENT METHODOLOGIES: CONCEPTUAL STUDY

 公開されている

SYSTEMS DEVELOPMENT METHODOLOGIES: CONCEPTUAL STUDY

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


System develoipment methodology(SDM)は、

システムの分析、設計、実装、保守を行う上で、

組織が従うべき標準的なプロセスである。

System development life cycle(SDLC)は、

システム開発をステップあるいは、フェーズに分けるものである。

SDLCは、計画、分析、設計、実装、保守の5つのステージを定義する。

計画では、開発のための計画が作られ、優先順位づけがなされる。

次は分析工程である。この工程では、要求が決定され、System Analysis(SA)

を使って構造化される。続く設計では、要求をもとに、情報システムの

アウトプットなどが設計される。

続く実装では、設計結果からコーディングとテストが行われる。

実装にはドキュメンテーションとトレーニングが含まれる。

ドキュメンテーションは、対象をインストールして利用しようとする

ユーザ向けに作られる。トレーニングは、ユーザにシステムの使い方を伝える。

システム開発が完了すると、保守フェーズに入る。ここでは既存システムの保守が

行われる。


1970年代には、ウォーターフォールモデルが提案された。

それ以降、ウォーターフォールモデルの欠点を克服する、あるいは、

効率化や、システム開発プロセスの品質改善に向けて、いろいろなモデルが

提案された。次にシステム開発のモデルを示す。

(1) 1970年代まで

 ・形式的技法

 ・コンポーネントベース開発

 ・リニアでシーケンシャルなモデル

(2) 1970~1993

   ・インクリメンタルでイテレイティブなモデル

   ・OODAD

   ・アジャイルモデル

(3) 1993~2000

   ・SOA

   ・Open Source development 

(4) 2000~

 ・現代アジャイルモデル 


1967年 形式的技法

1968年 コンポーネントベース開発

1970年 ウォーターフォールモデル

1970年代 プロトタイプモデル

1974年 Join Application and Development

1982年 Vモデル

1986年 スパイラルモデル

1990年代 アスペクト指向

1991年 Rapid Application Development 

1993年 Wモデル

1993年 スクラム

1994年 Concurrent Development

1994年 Dynamic Systems Development Method

1996年 Rational Unified Process 

1996年 Service Oriented

1997年 Feature Driven Development

1998年 クリスタル方法論

1998年 Open Source Development

1999年 eXtrem programming 

1999年 Adaptive Software Development

2002年 Agile Unified Process

2003年 Test Driven Development

2003年 Behavior Driven Development

2004年 kanban Software Development


SDM from 1970 to 1993

ウォーターフォールモデルが導入され、

システム開発が、よりフォーマルとなった。


Liner Sequence Model

Liner Sequence Modelは、ソフトウェアライフサイクルの

最初に十分な要求を収集し、それをベースラインとする。

システムの開発中は、その要求を変更することはできない。

システムが完成した後に、利用者は、フィードバックを行う。

この方法は、大規模で複雑なシステムに対して、有効である。

あらかじめ要件が、確定している。

この方法論の問題は、利用者のライフサイクルへの関与が薄いため、

保守コストが高いことにある。

リニアで、シーケンシャルなモデルには、

ウォーターフォールモデル、V-Model、W-Modelがある。


ウォーターフォールモデル

ウォーターフォールモデルでは、次のフェーズがはじまる前に、

それぞれのフェーズを完了する。

このモデルは、要求の変化が少ないプロジェクトに有効である。


V-Model

V-Modelは、ウォーターフォールモデルでの、システムの品質の

改善のためテストに焦点をあてたものである。

コーディング工程とユニットテストの工程を対応させ、

Low levelのデザインドキュメントが、コンポーネントテストのInputとなる。

High levelのデザインドキュメントが、統合テストのInputとなる。

System Requirement Specification(SRS)が、システムテストのInputとなる。

Business Requirement Specification(BRS)が、受入テストのInputとなる。

V-Modelは、成功したモデルで、広く企業で受け入れられている。


インクリメンタル・イテレーションモデル




--続きます--

2025年11月2日日曜日

入力チェックの種類

 1.ニューメリックチェック


数値として扱えるもののみ


2.シーケンスチェック


対象とするデータが一定の順番で並ぶ


3.リミットチェック


データが、定められた範囲内にあるか


4.フォーマットチェック


日付など、データ形式が正しいか


5.照合チェック


 入力されたコードが、マスターに存在するか、など


6.論理チェック


関連する項目間に矛盾がないか




2025年11月1日土曜日

O記法

 O記法

 計算量のオーダーを表す。次のようなオーダーが使われる。(速い順)

O(1) 

O(log n) 

O(n)

O(n log n)

O(n2)

 

線形探索法

先頭から順に調べる。

最悪は、O(n) 。最良は、O(1) 

 

二分探索法

データがソートされている場合に使われる。

最悪は、O(log n)。最良は、O(1)


挿入ソート

最悪は、O(n2)。最良は、O(n)

 

選択ソート

最悪、最良とも、O(n2)

 

バブルソート

最悪、最良とも、O(n2)

 

クイックソート

最悪、O(n2)。最良は、O(n log n) 


マージソート

最悪、最良とも、O(n log n)

 

 

 

 

 

 

 



まぎらわしい 「フェールXXX」

1.基本は、フォールトトレイランス 故障が発生しても、動作を続け、大きな可用性を実現する。 フォールトトレイランスを実現する考え方として 「フェイルセーフ」「フェイルソフト」などの考え方がある。 (1)フェイルセーフ(安全重視です) システムに障害が発生しても、部分停...