公開されている
An Empirical Study of Bad Smell in Conde on Maintenance Effort
のキモの部分を読んで勉強してみたいと思います。
概要
code smellの発見およびリファクタリングを自動化するツールを、
提案する。発見したcode smellに対して、リスクファクターを計算し、
リファクタリングのテクニックを利用して、リスクファクターを
軽減する。
リファクタリングは、ソフトウェアの振る舞いを変更せずに、
内部構造を改良するもの。
新しいcode smellである、Lazy Catchも発見できる。
オブジェクト指向ソフトウェア用のメトリクスを利用した。
イントロ
リファクタリングのプロセスは、多くのアクティビティを含む。
1.ソフトウェアのどこをリファクタリングするかを認識する。
2.1の中で、どこお実際にリファクタリングするかを判断する。
3.リファクタリングが、振る舞いを保存することを確認し、
リファクタリングを行う。
4.リファクタリングの結果を、ソフトウェアの保守性などから、
評価する。
5.リファクタリングしたソフトウェアと、他の資材
(ドキュメント、テストなど)との整合性を取る。
ソフトウェア保守
ソフトウェアの保守は、リリース後、ミスを訂正する、
パフォーマンスなどを改善するもの。
複雑な作業で、システムの理解も難しい。
保守のプロセスは、プログラマの経験やドキュメント、
システムそれ自体の特徴に影響を受ける。
Code smell
Code smellは、ソフトウェアの改良や保守を困難にする
設計やコードである。
Code smellを削除することで、保守性はあがり、
ソフトウェアの品質は向上する。
Code smellの発見には、標準的なメトリクス、
オブジェクト指向のメトリクス、ad hocに定義された
smell発見用のメトリクスが使われる。
次のようなメトリクスを利用した。
Number of Method (メソッドの数）・・対象は、クラス
Number of Parameters(パラメータの数)・・対象は、メソッド
Lack of Cohesion of Methods(凝集度の不足)・・対象は、クラス
Method Lines of Code(メソッドのコードのライン数)・・対象は、メソッド
Weighted Methods per Class(クラスの複雑度)・・対象は、クラス
Oracle Linux 8.10です。
1. ダウンロード
https://www.oracle.com/java/technologies/javase/jdk17-0-13-later-archive-downloads.html
から、
jdk-17.0.12_linux-x64_bin.tar.gz
をダウンロードしました。
2. 解凍
ダウンロードしたファイルを
/opt
の下で解凍します。
sudo tar zxvf jdk-17.0.12_linux-x64_bin.tar.gz
3.環境変数の設定
JAVA_HOMEとPATHを設定
$export JAVA_HOME=/opt/jdk-17.0.12
$export PATH="/opt/jdk-17.0.12/bin:$PATH"
4.確認
4-1 ソースの作成
次のようなソースを作成します。(SampleJava.java)
public class SampleJava {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}
4-2. コンパイル
$javac SampleJava.java
SampleJava.classができます
4-3. 実行
$java SampleJava
Hello World!
が出力されます。
動いているようです。
THE MOST COMMON FACTORS FOR THE FAILURE OF SOFTWARE DEVELOPMENT PROJECT
です。
セキュリティ機能を講じることで、故障、事項、エラー、犯罪等が発生する可能性を低下させる。管理の強化、システム監査の実施の公表など
事故、災害、犯罪の発生を未然に防止する機能であり、具体的には、防火・防犯装置の設置、地震対策、侵入対策、システムダウン対策。
事故、エラー、犯罪等の発生時に早期に発見し、被害を最小限に食い止める
事故・災害が発生した場合、情報システムを正常な状態に復元し、再開させる機能
GNOMEは、CentOS 9では、少し面倒くさそうで。
sudo dnf install -y epel-release
sudo dnf config-manager --set-enabled crb
sudo dnf group install -y "Xfce"
sudo dnf install -y xrdp xorgxrdp
sudo systemctl enable --now xrdp
sudo firewall-cmd --add-port=3389/tcp --permanent
sudo firewall-cmd --reload
ログインするユーザの$HOMEに、以下の.xsessionファイルを作成する。
exec startxfce4
その後
chmod +x ~/.xsession
sudo systemctl restart xrdp
Windowsのリモートディスクで、IPを指定して接続。
ネズミが上がってきました。
sudo dnf install glibc-langpack-ja
sudo localectl set-locale LANG=ja_JP.UTF-8
sudo localectl set-locale LC_MESSAGES=ja_JP.UTF-8
sudo localectl set-locale LC_TIME=ja_JP.UTF-8
sudo localectl set-locale LC_COLLATE=ja_JP.UTF-8
sudo localectl set-locale LC_CTYPE=ja_JP.UTF-8
sudo localectl set-locale LC_MONETARY=ja_JP.UTF-8
sudo localectl set-locale LC_NUMERIC=ja_JP.UTF-8
sudo localectl set-locale LC_PAPER=ja_JP.UTF-8
sudo localectl set-locale LC_NAME=ja_JP.UTF-8
sudo localectl set-locale LC_ADDRESS=ja_JP.UTF-8
sudo localectl set-locale LC_TELEPHONE=ja_JP.UTF-8
sudo localectl set-locale LC_MEASUREMENT=ja_JP.UTF-8
sudo localectl set-locale LC_IDENTIFICATION=ja_JP.UTF-8
sudo dnf install -y langpacks-ja glibc-langpack-ja
sudo fc-cache -fv
sudo systemctl restart xrdp
再接続すると、ディスクトップが、日本語になりました。
sudo dnf install -y firefox
xfceのメニューに、[インターネット] - [FireFox]ができました。
公開されている
A Catalog and Classification of Fortran Refactorings
のキモ部分を読んで、勉強してみたいと思います。
概要
いろいろな品質特性を改良するリファクタリングのカタログを提供する。
リファクタリングを、その目的、リファクタリングで改良しよとする
品質に基づいて分類する。
はじめに
Fortranは、FORTRAN66、FORTRAN77、FORTRAN90/95、
Fortran 2003、Fortran 2008と進化してきた。
この進化の中で、古いバージョンとの後方互換性を担保していることが、
特徴である。
長い間にわたって進化してきた結果、プログラムの保守は難しくなっている。
リファクタリングは、コードの内部品質～可読性や柔軟性、理解容易性や
保守容易性など～コードの品質を改善するテクニックである。
リファクタリングは、コードの重複など、Bad smellsに対応する形で行われる。
また、リファクタリングは外部への振る舞いを変えない。
Fortranの場合、リファクタリングは、可読性や保守性を上げ、
新しい機能による明確な構造を与えることで、コードをモダナイズする。
-- つづきます --
STRIDEは、攻撃手法を分類するもの。
1.Spoofing identity なりすまし
別のIDになりすます。
2.Tampering with data 改ざん
データを改ざんする。
3.Repudiation 否認
自分の行った攻撃活動への関与を否認する。
4.Information disclosure 情報漏洩
5.Denail of Service サービス拒否攻撃
6.Elevation of privilege 権限昇格要
・フィーチャとは、顧客にとって価値があり
2週間以内に実装可能な機能。
・フィーチャを利用して、次のように開発をすすめる
1.全体モデルの開発
2.フィーチャリストの作成
3.フィーチャ単位の計画
4.フィーチャ単位の設計
5.フィーチャ単位の構築
(1) インターフェース
モジュールやクラス等のインターフェースの確認する
(2) 複雑度分析
メトリクスを用いて、複雑度を分析する
(3) トレース
想定される入力を想定して、プログラムの動きをトレースする
(4) 制御フロー
IF文などの制御構造に着目して、その正しさを分析する
公開されている
Using FDD for Small Project: An Empirical Case Study
のキモの部分を読んで、勉強してみたいと思います。
概要
Feature Driven Development(FDD)は、広く使われているアジャイルのメソッドの1つ。
FDDは、次のような多くの欠点を持つため、批判されてきた。
・経験豊かなスタッフへの依存
・要求収集に関するガイダンスの不足
・急な変更に対して、弱い
これらの欠点のため、FDDは変更の少ない、大きなプロジェクトだけに
適用できるとされてきた。
この論文は、FDDを、小さなWebプロジェクトに適用して、FDDが、
規模の大きなプロジェクトにしか適さないかを、検証するもの。
小さなプロジェクトでよく使われるXPと比較する。
イントロ
スクラム、XP、DSDM、クリスタルメソッド、TDD、FDD
など多くのアジャイルメソッドが使われている。
それぞれの方法論には、それぞれに適した開発アーキテクチャがあり、
それぞれ適しているプロジェクトが異なる。
しかし、すべての方法論は、アジャイルマニフェストで宣言された
原則に従っている。
このマニフェストは、すべてのアジャイルプロセスモデルの元となる
ドキュメントと考えられており、ソフトウェア開発の12の基本的なルールを含む。
これらの原則には、チームの頻繁なコミュニケーション、顧客満足、
要件の変更のマネジメント、等を含む。
アジャイルのチームは、自己組織化されたチームで、
メンバーは近くで協同する。
さらにアジャイルマニフェストは、シンプルなデザイン、
信頼性や品質の高いソフトウェアの高頻度、タイムリーなデリバリー
にフォーカスしている。
アジャイルは、イテレーディブなプロセスで、それぞれのイテレーションで、
動くモジュールを作成する。
イテレイティブな開発は、それぞれのイテレーションで、
顧客からのフィードバックがあるため、顧客にも、開発者にも高い満足をもたらす。
FDDは、最も広く使われているアジャイル開発モデルの1つである。
FDDは、プロセス志向で、ユーザ中心のモデルであると言われている。
FDDは、5つのフェーズからなる。
1. 全体をカバーするモデルを作成する
2.機能リストをつくる
3.機能について計画する
4.機能を設計する
5.機能をbuildする
それぞれのフェーズは、多くのアクティビティやタスクを含む。
このため、FDDは、重い方法論であるという批判もある。
そのため、FDDは、経験が必要で、要求の変更を適切にコントロール
することも必要となり、中規模から大規模なプロジェクト向けと言われている。
--つづく--
最大公約数を探すアリゴリズム。
XをYで割った時の剰余をRとすると、
XとYの最大公約数は、YとRの最大公数に等しい
この定理を利用し、
R=0となるまで、YとRを変えながら、探す。
X ≧ Y とする。
1. X÷Y を Rとする
2.R が0 でない間、3から5を繰り返す
3.XにYを代入
4.YにRを代入
5.X÷Y を Rに代入
6.R=0となった時のYが最大公約数
