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
が出力されます。
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
が出力されます。
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.計画
プロジェクトのレビュに基づき、スパイラルの次のループを実行するかを、
決定する。
スパイラルモデルの、他のモデルとの違いは、明示的にリスクを認識すること、
である。
リスクが特定され、それに対する開発を実行した結果で、次のフェーズの
計画を作ることとなる。
MPA
・Multi Page Application
・リクエストのたびにブラウザとサーバの間の通信が発生する。
SPA
・Single Page Application
・最初にサーバからHTMLやJavaScriptをダウンロードし、
以降はJavaScriptでサーバと通信する。
画面全体の書き直しは、発生しない。
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が実行される前後の処理、例外処理などに使われる。
1. ファイルの作成
tomcatのインストールディレクトリ/webapps
の下に
test
ディレクトリを作成します。
testディレクトリの下に、以下のような、helloworld.txt
を作成します。
hello world
2. 確認
tomatを起動し、ブラウザーで、
http://localhost:8080/test/helloworld.txt
を指定すると
hello world
が表示されます。
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
で停止しました。
公開されている
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は、成功したモデルで、広く企業で受け入れられている。
インクリメンタル・イテレーションモデル
--続きます--
1.ニューメリックチェック
数値として扱えるもののみ
2.シーケンスチェック
対象とするデータが一定の順番で並ぶ
3.リミットチェック
データが、定められた範囲内にあるか
4.フォーマットチェック
日付など、データ形式が正しいか
5.照合チェック
入力されたコードが、マスターに存在するか、など
6.論理チェック
関連する項目間に矛盾がないか
計算量のオーダーを表す。次のようなオーダーが使われる。(速い順)
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)
1.基本は、フォールトトレイランス 故障が発生しても、動作を続け、大きな可用性を実現する。 フォールトトレイランスを実現する考え方として 「フェイルセーフ」「フェイルソフト」などの考え方がある。 (1)フェイルセーフ(安全重視です) システムに障害が発生しても、部分停...