code smell の例

 コードの重複

長いクラス

長いメソッド

不適切なコメント

単一責務違反

複雑な判定条件

不適切なネーミング

Webのパフォーマンスのテスト/チェック内容の例

 1.ページロードの時間は、想定内か？

2.ネットワークが細い状態でのページのロード時間は？

3.アクセスが、少ない、普通、多い状態でのレスポンスの時間は？

4.データベースのストアードプロシージャやトリガーのパフォーマンスは？

5.データベースへのQueryの実行時間は

6.アプリケーションのロード時間は？

7.アプリケーションに負荷がかかった状態でのレスポンスは？

8.ビーク時のCPUやメモリの負荷は？

バージョン管理システムの用語

リポジトリ

バージョン管理を行うファイルや構成情報を管理する場所。

チェックアプト

リポジトリから編集のためにファイルなどを取り出す。

作業用コピーがつくられる。

チェックイン

変更をリポジトリに保存する。

更新

リポジトリに(他の人が)加えた変更を作業用コピーに反映させる。

コンフリクト

同じコードの同じ部分を、異なる人が、更新してしまう。

ロック

指定したファイルを、他の人が変更できないようにする。

Webエンジニアリング

WEBアプリケーションの仕様化と分析

仕様化とは、次の問いに答えること 

 ・Webアプリケーションが必要となる主要なモチベーションは、何か？ 

 ・誰が、Webアプリケーションを必要としているか？ 

 ・誰が、Webアプリケーションを使うか？ 

 これを基に、目標を設定する。 

 目標には、次が含まれる。 

 ・どんな情報やコンテンツを提供するか 

 ・Web App で何ができるのか 

 分析は、要件を定義するものであるが、Web特融の点としては、以下がある。

1．コンテンツの分析

　Webアプリケーションで提供するコンテンツを特定する 　データモデリング手法も利用できる。

2．インタラクション分析

　ユーザとのかかわり合いを分析する 　ユースケースを利用できる。

3.機能分析

　　ユースケースシナリオを作り、オペレーションや機能を特定する。

4.コンフィグレーション分析

　Webアプリケーションの環境やインフラを定義する。

 

Webアプリケーションの設計

アーキテクチャ・デザイン

　Webベースのシステムのアーキテクチャデザインは、Webのコンテンツの構造を定義する。

ナビゲーションのデザイン

異なるロールのユーザに対して、アクセスできるコンテンツが異なる場合がある。 

その時、個々のロールに応じたナビゲーションを決定する必要がある。 

 また、ナビゲーションの手段として、テキストベースのリンク、アイコン、ボタン、画像等から適切なものを選択する。 

また、ボタンが押せる、押せないを、ボタンの形状で変える、テキストベースのリンクの色で変更する等からも選択する。 

 これ以外にも、サイトマップの利用、インデックス、サーチエンジン、helpの利用等を考慮する必要がある。

 

インターフェースのデザイン

インターフェースのデザインに関していは、次のようなものがある。

 ・サーバエラーを、利用者に見せない 

 ・レスポンスを保つため、テキストや画像の両をしぼる 

 ・スクロールを少なくする 

 ・メニュー、ナビゲーション、ヘッダー、フッターは、統一し、すべてのページで利用可能とする 

 ・意図が伝わらないアイコン、画像等はさける

クロニクル GCEでhttpサーバをあげてみる

 サーバは、作成済みとします。今回は、Red Hat Enterprise Linux release 10.0

です。

1.Apacheをインストール

sudo yum install -y httpd

2.サービスを起動する

sudo systemctl start httpd

3.ファイアウォールで、HTTP / HTTPSを許可

許可してリロードします。

sudo firewall-cmd --permanent --add-service=http

sudo firewall-cmd --permanent --add-service=https

sudo firewall-cmd --reload

4,サーバのあるVPCのファイアウォールは、空いているとします。

5.ブラウザでアクセスしてみる。

http://<サーバのIP>

でアクセスすると、

Test Page

が表示されました。

ソフトウェア 設計の原則(SOLID原則)

SRP:単一責任の原則

クラスを変更する理由は、1つだけ。

 

OCP:オープン・クローズドの原則

ソフトウェアの構成要素は、拡張に対して開いていて、 修正に対して、閉じていなければ、ならない。

 

ISP:インターフェース分離の原則

クライアントが利用しないメソッドへの依存を強制しては、 ならない。

 

DIP:依存関係逆転の原則

・上位のモジュールは、買いのモジュールに依存しては、ならない。 　どちらも「抽象」に依存すべき 

 ・抽象は、実装の詳細に依存しては、ならない。 　実装の詳細が、抽象に依存すべき

enabling PaaS application using Twelve-Factor App

 公開されている

enabling PaaS application using Twelve-Factor App

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

 

概要

クラウドコンピューティングのメリットを得るためには、

クラウドネイティブの原則に従う必要がある。

この論文では、伝統的なJavaのエンタープライズ・

アプリケーションを、クラウドネイティブ・

アプリケーションへ変換したことを対象としている。

Docker 、Kubernate、OpenShift などのクラウド関連技術、

Jenkisなどの自動化技術を利用した。

Twelve-Factor Appの方法とクラウド・ネイティブの原則に

従った。

 

イントロダクション

クラウドコンピュータ上のアプリケーションは、伝統的な

アプリケーションとは異なる。

クラウドの便益を得るための特徴を持っている。

自動化されたプラットフォーム、インフラやネットワークの

ソフトウェア化、マイグレーション、異なるクラウドインフラでの

相互運用性などである。

このような種類のアプリケーションは、クラウドネイティブ・

アプリケーションと呼ばれる。



1.1 背景

 伝統的なエンタープライズ・アプリケーションの中で、

最も有名なものに、Java EEがある。

 Java EEは、企業の環境やインターネット環境で、

 分散システムを構築するために利用される。

 

1.2 問題

Javaのエンタープライズ・アプリケーションを、クラウドへ

どう、マイグレーションするか？

Twelve-Factor Appは、PaaSのアプリケーションを構築する際に、

よく知られた方法である。そして、クラウドネイティブの

原則に従うことで、クラウドコンピューティングのメリットを得る

ことができる。 

このプロジェクトは、伝統的なJavaアプリケーションを、

 クラウドネイティブの原則、Twelve-Factor Appの方法に従って、

クラウドネイティブ・アプリケーションへ変換したもの。

 

2.1.1 JavaEE

Javaは、汎用的なコンピュータ言語で、並列処理、

クラスベース、オブジェクト指向の特徴を持つ。

大規模な分散システムでは、JavaEEが利用される。 

Javaは、write once , run anywhere と言われる。

JVMを利用することで、コンパイルされたJavaのコードは、

再コンパイルなしで、別のプラットフォームでも、動く。

JavaEEのコードは、bytecode へ変換され、

 Web Application Archive(WAR)や、

Java Archive(JAR)などへパッケージングされる。

WAR あるいは、JARファイルは、必要となるすべてのクラスファイルを

含む。

WARやJARファイルは、Tomcatのようなアプリケーションコンテナへ

deployされる。 

これらのアプリケーションコンテナは、HTTPSやJDBCなどの

機能を提供する。



ソフトウエア開発では、次のような環境が利用される。

1.Development 

開発者用の環境

2.Integration 

すべての開発者がコードをコミットする

3.Staging

Production環境をシミュレートする

4.Production

アプリケーションが提供される環境

 

クラウドコンピューティング

クラウドコンピューティングの利点としては、次がある。

・無限のリソースを、オンデマンドで調達できる。

・利用者の増加に対応することができる。

・短期間だけ必要なコンピュータリソースを準備することが容易

・巨大なデータセンターを利用することでの規模の経済性

・オペレーションが単純になる

 

SaaS と Cloud-Native Application 

クラウドコンピューティングのメリットを得るためには、

アプリケーションもスケーラビリティ、保守性、ポータビリティなどに

対応する必要がある。

これに対応したものが、Cloud-Native Application 。

次の原則を満たすものである。

・自動化されたプラットフォーム上で稼働する

・インフラとネットワークをソフトウェア化する

・異なるクラウド上での相互運用性

 

Twelve-Factor Appは、SaaSを作るときのベストプラクティス。

Twelve-Factorを使って作ったアプリケーションには、

以下の特徴がある。

・セットアップの自動化のために、明示的な宣言を使用して、

ディプロイのための時間やコストを最小化している。

・ＯＳの以下と、クリーンな関係で、実行環境のポータビリティ

を最大化している。

・クラウド環境でのディプロイに最適化。

・開発と製品の間を最適化。継続的ディプロイで、

アジリティを最大化している。

・ ツールやアーキテクチャ、開発のプラクティスの

重大な変更を伴わないスケールアップ。



Twelve-Factor Appは、次のもの。

 1. コードベース

1つのアプリケーションは、1つのリポジトリに対応し、

1つのリポジトリには、異なる環境のソース等が含まれる。

これは、開発者の生産性に関して有効である。

リポジトリには、アプリケーションをビルドして実行する

ために必要なすべてのソース、コンフィグファイルなどが含まれる。

 

2.依存性

アプリケーションを実行するためには、宣言を明示する必要がある。

バージョンを指定するころで、互換性の問題にも対処する。



3.設定

設定は、コードに依存するもの。一方、コードは設定に依存しない。

環境によって異なる設定は、アプリケーションの外部から動的に変更する。

設定は、そのためのファイルや環境変数などを利用する



4.Backing Service

Backing Serviceとは、アプリケーションがアクセスする

データベースや外部のアプリケーションのこと。

これらは、アプリケーションとは疎結合とする。

つまり、アプリケーションに影響を与えることなく、

新しいインスタンスに置き換えることができる。



5.Build , Release , Run

BuildとReleaseとRunは、別のステップとして実行する。



6.プロセス

アプリケーションは、ステートレスとして実行する。

ステートは、外部のデータベースへ保管する。



7.Port Binding 

サービスは、Port Bindingで公開する。

アプリケーションは、その機能をネットワークポートを通じて、

提供する。



8.Concurrency 

アプリケーションのスケール性を保証する。

アプリケーションは、水平、垂直のスケーリングができる。



9.Disposability

アプリケーションは、クラウド上で、restartされる。

リソースに対する接続を適切にcloseすることなど。

適切にシャットダウン、スタートアップできること。



10.Dev/prod Porting 

環境間の差異を最小限にすること



11.Logs

ロギングは、アプリケーションのパフォーマンスに

大きな影響をもたらす。



12.管理プロセス

管理のためのプロセスは、独立した短いプロセスとする。

管理のためのタスクは、デバグやトラブルシューティングの

ために必要となるものである。



クラウドテクノロジー

Dockerは、容易な相互運用性やマイグレーションを実現するために利用される。

Open Shitは、kubernateに基づき、弾力性のあるプラットフォームを

提供するために利用しリソースのプロビジョニングを行う。

Dockerも、Open Shiftも、インフラのソフトウェア化のために利用される。


コンテナ:Docker

クラウドコンピューティングでは、リソースはシャアされる。

仮想化のためには、virtual machine とコンテナの2つの技術が利用される。

virtual machine は、物理的なハードウエアの上にパイパーバイザーと呼ばれる

ソフトウェアがあり、パイパーバイザーが物理的なリソースを抽象化する。

この技術は、1つのハードウエアの上へ複数の環境を作ることができる。

この環境のことを、virtual machine といい、IaaSを提供するテクノロジーとして、

提供される。このテクノロジーにも欠点がある。

各virtual machine は、それぞれOSのイメージを持ち、メモリやストレージの

オーバヘッドとなる。

MVVM

 Model , View , View Model (MVVM pattern)は、次のような分割である。

Model 　　  データを保持するだけで、ビジネスロジックは持たない

ViewModel   ModelとViewをつなぐ

View             フォーマット化されたデータを保持する

責務は、次のとおり。

(1) Model 

・オブジェクトを保持する

・オブジェクトの変更を通知する

・データのバリデーション

(2) View 

レイアウト

(3) ViewModel 

・Viewにデータを提供する

・ロジックを提供する

コードのチューニングテクニック

・評価( if  , case)は、真になる可能性が最も高いものが、最初に実行されるようにする


・最も回数の多いループを、内側へもってくる


・配列の次元を削減する

Cloud Native Software Engineering

公開されている

Cloud Native Software Engineering

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

概要

クラウドネイティブなアプリケーションに関しての

ソフトウェアエンジニアリングのプラクティスは、少ない。

クラウドネイティブなアプリケーションは、

クラウドプラットフォーム向けに設計、実装され、

ディプロイされるソフトウエアのこと。

この論文は、クラウドネイティブなソフトウェアエンジニアリングの

概要を目指す。

クラウドネイティブ・コンピューティングとは

次の特徴を持っている。

Well Architected System

ソフトウェアエンジニアリングのベストプラクティスを

提供するだけではなく、機能、非機能をクラウドが提供する。

たとえば、認証の実現、セキュリティ要件への対応、

信頼性や、スケーラビリティへの対応などである。

-- つづきます --

Rapid application development(RAD) : an empirical review

 公開されている

Rapid application development(RAD) : an empirical review

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

イントロ

Rapid application development(RAD) は、James Martin が提唱したもの。

Martin は、RADのキーとなる目標に関して、

高品質のシステムを高速にローコストで開発する

としている。

RADの方法論の1つとして、

dynamic systems development method (DSDM)がある。

DSDMは、次の5つのエリアをカバーしている。

(1) Model of development process

DSDMは、イテレイディブで、インクリメンタルなモデルである。

(2) Set of techniques

DSDMは、joint requirements planning work shop や

joint application design workshop 、タイムボックスなどの

概念を提唱しているが、ER図など伝統的な方法も利用する。

(3) Documentation methods

(4) 哲学

RADのコンポーネントには、次がある。

Joint application design(JAD)

RADは、4～8人の小さなチームで行う。

利用者と開発者から成り立っており、意思決定の権限がある。

Joint application development workshop(JAD)

要求の引き出しなどで広く使われる。

このワークショップの中で、主要なユーザ、クライアント、開発者が

ファシリテーターの元、システムのスコープやビジネス要求を決めていく。

開発者は、3～5日でビジネス要求をドキュメント化することが

期待される。

Rapid of development

RADのプロジェクトは、比較的、小規模短期間である。

一般的には、2～6か月が普通であると言われる。

Clean rooms

JADのworkshopは、通常のビジネスや開発の現場から離れた

クリーンルームで行う。クリーンルームは、通常の仕事からは離れ、

ポストイットのような必要なものが揃った場所である。

ここで問題解決に集中する。

Incremental prototyping

プロトタイプは、システムをインクリメンタルに構築していく方法。

開発者は、最初の調査の直後、モデルを作ってユーザへデモを行う。

開発者とユーザーは、プロトタイプについて、議論し、

改善に合意する。

RADプロジェクトでは、この検査-議論-改善のプロセスが、

3回は、繰り返される。

プロトタイプは、要求の収集、アプリケーションのデザイン、

アプリケーションのBuild、テストなど、どの工程でも利用できる。

RADは、インタラクティブな要素が多く、複雑でないプロジェクト

で利用されている。

Dynamic System development method(DSDM)

DSDMは、RADの方法論の1つである。

DSDM Principle

1.ユーザの参加は必須

2.DSDMのチームは、意思決定を委譲されている

(つづきます)

テスト技法

同値分析法

同じ結果となる入力の範囲を同値クラスとして、

同値クラスの代表値のみをテストする。

境界値分析法

同値クラスの境界の上限や下限などをテストする。

ディシジョンテーブル法

テスト対象をディシジョンテーブルをもとに作成し、

漏れを防ぐ。

バケットソート

 (3,6,1)を昇順にソートする例です。

1. (3.6.1)の最大値を見つける。

　この場合は、6

2.1の最大値分の配列を用意する。

　例えば、a[6]とする。

3.a[6]の各要素を初期化する。

　例えば、0とする。

4.(3.6.1)の最初の要素から次を繰り返す。

5.最初の要素(3)を、その添え字にもつa[6]の配列に、

　その値を入れる。

    a[3] = 3 

6.次の要素(6)を、その添え字にもつa[6]の配列に、

　その値を入れる。

　a[6] = 6

7.a[6]の配列の中で、初期値でないものを順に取り出すと、

　ソートされている。

A Comparison of User Experience in Progressive Web Apps and Cross-platform Framework Apps

 公開されている

A Comparison of User Experience in Progressive Web Apps and Cross-platform 

Framework Apps

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

概要

モバイルアプリケーションでは、クラスプラットフォームでの開発が進んでいる。

クロスプラットフォームのフレームワークは、数多くある。

Progressive Web Appでのアプローチは、数好きない。

Progressive Web Appは、オフラインでも利用できるもので、

ブラウザで動作することで、クロスプラットフォームを実現する。

しかし、利用者には、普通のアプリに見える。

この年休は、クロスプラットフォームとProgressive Web Appでの

UXの違いを、パフォーマンス、機能評価、外観の違いから比較する。

また、起動時間、バッテリーの使用、アプリのサイズ、機能のロード時間

を測定した。そして、カメラ、シェア、通知、認証などの見た目や機能を

評価した。

評価のため、2つのアプリケーションを作成した。

Progressive Web Appは、Reactで、クロスプラットフォームは、

React Nativeで作成した。両方のアプリが同じ機能を実装する。

この2つのパフォーマンス、外観、機能を、AndroidとiOSで比較する。

結果、低スペックの端末では、React Nativeのアプリが、

Progressive Web Appsを上回り、見た目や機能性も、より、

ネイティブアプリに近いことが示された。

ただし、その差は小さい場合が多く、クロスプラットフォーム開発においては、

Progressive Web Appも有効な選択肢となる。

しかし、伝統的なWeb appには、いくつか制限がある。

ブラウザで動かすこととなるため、スクリーンには、

アドレスバーが現れる。

また、ハードウェアへのアクセス、ハードウェアが提供する機能、

ローカルストレージの利用、通知などに制約がある。

 Progressive Web Apps(PWAs)は、これらの制限を克服するための機能を

Web appに導入するもの。

PWAは、オフラインでも利用できる。

Webからインストールでき、普通のアプリのように動作するが、

app storeは、必要ない。

PWAでクロスプラットフォームのappを開発する時は、OSが提供する

いくつかの機能とUIを使うことができるため、

ネイティブアプリのような外観が実現できる。

この研究は、ReactでつくったPWAと、React Nativeでつくった

アプリとのUXの比較である。

問題

マルチプラットフォームのアプリを開発する場合、PWAを利用するか、

クロスプラットフォームのフレームワークを利用するかの選択肢がある。

この選択肢は、1つのcodebaseで、複数のプラットフォームへ対応する

ニーズから出ている。

この研究のリサーチクエスチョンは、次である。

RQ1:Reactで作られたPWAsとReact Nativeで作られたアプリで、

起動時間、バッテリーの利用、アプリのサイズ、機能のロード時間が、

どのように異なるか?

起動時間、バッテリーの利用、アプリのサイズなどのパフォーマンスは、

UXにとって重要である。ユーザ入力後のレスポンスタイムも重要である。

RQ2:Reactで作られたPWAsとReact Nativeで作られたアプリは、

機能や見た目がどう異なってくるのか。

OSが提供するUIと似たものになれば、UXに大きなインパクトを与える。

目的

PWAとクロスプラットフォームのappの間のUXの差異には、どのような

要素があるかを評価する。

1.Reactを使ったPWAとReact Nativeを使った、同じシンプルな

　アプリを作る。

2.2つのアプリから、パフォーマンス、外観、機能に関するデータを得る。

3.2つのアプリの類似点や差異を抽出する。

モバイル開発

Native 

ネイティブアプリを開発する伝統的な方法は、OSに合わせた手法である。

OS特有のSDKや言語を利用する。OSが提供するAPIを利用して、

OSの機能を直接利用する。

これにより、Look&Feelは、一般性があるものとなる。

それぞれのOSは、独自のAPIを持つため、それぞれのOSをターゲットとした、

codebaseが必要となる。

Androidのアプリケーションは、Androidのフレームワークを利用して、

Javaあるいは、kotlinでプログラムされる。

一方iOSでは、Appleのフレームワークを利用し、

objective-cあるいは、swiftでプログラミングされる。

異なるSDKやフレームワークに対応した複数のcodebaseを開発、維持していくのは、

コスト高につながる。

そこに1つのcodebaseで複数のプラットフォームに対応できる

クロスプラットフォーム開発のメリットがある。

クロスプラットフォーム開発

クロスプラットフォーム開発は、1つのアプリケーションで、

複数のプラットフォームに対応するもの。

複数のプラットフォームに対して、同一のcode baseで対応することができる。

クロスプラットフォーム用のフレームワークを利用する。

フレームワークは、各ブラットフォームのAPIをラップする抽象化レイヤを作る。

この抽象化レイアが、プラットフォームの違いを吸収する。

Web App

単一のcode baseで、クロスプラットフォームを実現することは、

モバイルデバイス上のWebブラウザでwebアプリを実行することで、

達成できる。

このアプリは、HTML、CSS、JavaScriptで作られ、

モバイルデバイス用に最適化されている。

このアプローチには、欠点もある。ブラウザーの

アドレスバーなどに大きな面積をとられること、

デバイスやシステムが提供する機能へのアクセスに制限があること、

オフラインでは利用できないこと、である。

Progressive Web Apps

PWAsは、webアプリケーションで、Web APIを利用することで、

アプリのようなUIを実現するもの。

PWAは、ネイティブアプリの利点と、Webアプリの利点の両方を実現するもの。

インストールでき、オフラインでも利用でき、デバイスやシステムの機能に

アクセスできる。webを通じて得ることができ、アプリストアが必要ない。

単一のcode baseで、いくつかのプラットフォーム上で稼働する。

webサイト同様、PWAはURLを通じて、アクセスできる。

app manifestが、インストールに必要な情報を提供する。

インストールされると、PWAは他のアプリと同じように見える。

アイコンがスクリーン上に現れ、フルスクリーンで開き、

アプリケーションのスイッチャ上に現れる。

PWAは、ブラウザーで動いてはいるものの、ユーザには、

他のアプリと変わりない。

Service workerを使うことで、PWAは、オフラインでも利用できる。

また、push通知なども実現できる。

PWAのインストール

PWAは、ブラウザーからインストールすることができ、

アプリストアが必要ない。

ブラウザでURLへアクセすることで、PWAにアクセスできる。

そして、普通のアプリとして利用できる。

App Manifest

PWAのエッセンシャルな部分に、app manifestがある。

app manifestは、JSON形式でアプリの外観と振る舞いを記述するもの。

アプリの名前、アイコンなどを指定する。

React

Reactは、Webアプリを開発するオープンソースのJavaScriptのライブラリ。

UI、ロジック、外観についてのコンポーネントを扱う。

Reactのアプリケーションを作るためには、React projectのセットアップツール

を利用する。そこで使われるテンプレートは、PWAsをサポートする。

App Manifestファイルと、キャッシュのロジックを実装する

サービスワーカーfileを含む。

デフォルトのままでも、静的なアセットはキャッシュされ、PWAが

オフラインでも利用できるようになる。

React Native and Expo

React Nativeは、オープンソースのプラットフォーム

開発用のフレームワーク。

Reactに基礎を置き、クロスプラットフォームのために、

JavaScriptを利用する。

React Nativeは、アプリのUIや機能を作るためのコンポーネントと、

APIを含む。開発者は、コンポーネントやAPIをJavaScriptで利用し、

デバイスでは、JavaScriptがネイティブプラットフォームにアクセスする。

この方法で、プラットフォームSDKをコンポーネントやAPIに隠蔽する。

React Nativeプロジェクトでは、Expoという追加のプラットフォームが、

活用できる。

Expoの一部に、ExpoSDKがあり、React Nativeに含まれないコンポーネント

ライブラリを活用できる。

--つづきます---

Understanding the Correlation between Code Smells And Software Bugs

 公開されている

Understanding the Correlation between Code Smells And Software Bugs

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

概要

バグ予測は、ソフトウェアの品質保証を助ける。

ソフトウェアのテストに必要なeffortが予測できるためである。

アンチパターンとcode smellは、コード品質に大きな影響を持つと言われる。

リファクタリングは、これらアンチパターンの負のインパクトを取り除く

ものである。

この論文では、code smellの影響とバグの重大度に関するもの。

BIRT、AspectJ、SWTのプロジェクトの複数のバージョンから分析する。

異なるcode smellとバグの重大度の間の相関関係を分析した。

イントロ

コード中のエラーは、重大度に基づく優先度順に修正する必要がある。

ソフトウェア開発にかかわる費用の80%が、バグFixに使われている、

という報告もある。

このコストを削減するため、多くのバグ予測モデルが提案された。

これらのモデルは、ソフトウェアシステム中のどこにバグばあるかを、

予測するものである。

バグ予測モデルの多くは、コードの複雑度や

プロセス(code churn)などのメトリクスが利用される。

開発者はコードの中にcode smellを入れてしまうことがある。

こららのアンチパターンやcode smellは、システムの機能には

影響を与えないが、保守を困難にする。

code smellは、また、バグを生む可能性がある。

過去の研究では、code smellを含むclassは、そうでない

classに比較して、バグ proneであった。

バグを減らすためには、code smellを減らす必要がある。

これを行うのが、リファクタリングやコードの再構築である。

アンチパターンやcode smellを削減するリファクタリングや

再構築のツールは、数多くある。

code smellとdefectの間の関係がわかることには、意味がある。

そこで、code smellとバグの間の関係を、wekaが提供する

機械学習のアルゴリズムで測定することに挑戦した。

データは、BIRI、SWT、AspectJ の3つのオープンソースから

抽出した。

次のリサーチクエスチョンに応えるものである。

RQ1:code smellは、バグの重大度と関係があるのか?

code smellのいくつかは、他のcode smellより重大度に

インパクトを与えるものとした。

RQ2:機械学習のアルゴリズムで更なる情報がわかるか

code smellは、重大度に影響するだけではなく、

バグの数にも影響した。

方法

code smellの発見器では、次のようなアンチバターンが発見できる。

Cyclic Dependency

2つ以上のモジュールが、直接あるいは、非直接的にでも、

お互いに依存している。

Blob Class

すべての機能を持ち、すべての責務を持つClass。

God Class

多すぎる数のクラスをコントロールする。

大きすぎるロジックを持つクラス。

Data Class

データと、そのセッター/ゲッターのみを持つクラス。

Schizophrenic Class

関連しない/利用されないpublic methodを持つクラス。

Refused ParantBequest

サブクラスで、親クラスから継承したメソッドや、

プロパティの一部しか利用していないクラス。

-- つづきます。--

The Impacts of Low/No-Code Development on Digital Transformation

公開されている

The Impacts of Low/No-Code Development on Digital Transformation

and Software Development 

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

概要

Low/No-Code 開発は、ビジュアルに、ほとんど、あるいは、全く

コードを書くことなく、ソフトウェアを開発するもの。

これを使えば、ITのプロフェッショナルでない人が、コードを書くことなく、

迅速な開発ができる。

Low/No-Codeは、将来のソフトウェア開発やDXへ大きな影響を与えることが分かった。

1.イントロ

企業や組織はマーケットの要求に対応するためのツールを必要としている。

Low/No-Code開発は、ビジュアルなソフトウェア開発で、

ドラッグ＆ドロップやコンポーネントを接続するだけで、

モバイルアプリやWebアプリケーションを作ることができる。

Low/No-Code開発は、多くの利点があるものの、

次のような観点から、利用を控えるむきもある。

・ベンダーロックイン

・柔軟性の欠如

・セキュリティへの不安

・スケーラビリティ

しかし、柔軟性やスケーラビリティ、セキュリティは克服されてきている。

メリットと制限

(1) メリット

Low/No-Code開発で達成しようとするゴールは、数多くある、

変化への対応の改善、スキルを持つ人への依存を下げる等である。

(1-1)迅速さ

Low/No-Code開発は、アプリケーションを視覚的に作るため、

プロトタイプも容易につくれ、テストも迅速にできる。

Low/No-Codeを利用している多くの企業でアプリケーションの開発スピードが、

5～10倍になったという。

(1-2) 市民開発

市民開発は、IT部門に認められた開発者が、ツールを使って、

アプリケーションを開発し、配布すること。

市民開発では、プログラミングす来るは不足しているものの、

他のフィールドでの知識や経験は、豊富である。

これを生かして、必要なアプリケーションを作っていく。

(1-3)セキュリティ

 Low/No-Code開発プラットフォームは、シャドーITのリスクを低減することに役立つ。

IT部門がデータやアプリケーションをコントロールすることで、セキュリティを担保する。

Low/No-Codeプラットフォームの中で、利用されるコンポーネントやブロックが、

セキュアで、再利用可能で、最適化されていれば、それをまた利用したアプリケーションも

セキュアで最適化されたものになる。

Low/No-Codeプラットフォームの利用は、セキュリティテストの時間を短縮する。

ブロックなどのテストが不要なためである。

(1-4) 保守性

Low/No-Codeプラットフォームは、集中的で単一の環境を提供するため、

複雑性やアプリケーションの保守等のむつかしさを減らす。

さらに修正するコード数も少ないことが保守性を向上させる。

(2) 制限

組織が、Low/No-Codeプラットフォームを採用したない理由には、次がある。

(2-1) 知識の不足

(2-2) ベンダーロックインへの懸念

(2-3)セキュリティへの懸念

(2-4)カスタマイズや柔軟性に関する懸念

Low/No-Codeのビルディングブロックは、固定されていて柔軟性があるとは言えない。

Low/No-Codeで提供されていない機能を開発しようとすると、時間が必要となる。

一貫性や柔軟性を担保することは、難しい。

(2-5) スケーラビリティに関する制約

Low/No-Codeは小規模なアプリケーションで利用されることが多く、

大規模で複雑、クリティカルなアプリケーションで利用されることは少ない。

それは、スケーラビリティの不足のためである。

(2-6) セキュリティに関する懸念

Low/No-Codeプラットフォームベンダーへ依存すると、データやコードが自組織で

コントロールできなくなる。さらにプラットフォームベンダーがGive Upした場合、

それ以降のセキュリティUpdateはなく、自組織で対応する必要がある。

(2-7) ベンダーロックイン

結論

DXのためにLow/No-Code開発は必要となってきた。

DXが進につれ、ビジネスアプリケーションは、より複雑で専門的になっていく。

Low/No-Code開発は、アジリティ、フレキシビリティ、カスタマイズ対応などに

効果がある。プラットフォームは、セキュアなブロックを提供するが、

データアクセスやソースコードのアクセス制御の不足が、セキュリティ上の問題

を引き起こす可能性がある。

作られたコードのメンテナンスは容易であるが、ベンダーロックインの懸念がある。

Low/No-Code技術にも、改善点は多い。

現在のLow/No-Codeのプラットフォームマーケットを見ると、

AIとMLへの取り組みがキーとなりそうだ。Low-Codeから、No-Codeへの進化も

キーとなりそうだ。

クロニクル MacでJava(Eclipse)

 Pleiades All in Oneを利用します。

1. ダウンロード

https://willbrains.jp/

から、

Mac用Javaをダウンロードしました。

1.58Gもあった。時間かかります。

2.インストール

ダウンロードした

pleiades-2025-06-java-mac-jre_20250615.dmp

をダブルクリックして、インストール。

3.起動

アプリケーションから

Eclipse_2025-06

を実行。

「Appleは検証できませんでした」

エラーが出るので、こちらのページの通り対処して起動しました。

https://www.century.co.jp/support/faq/macos-error.html

4.確認

Eclipseが起動してくるので、メニュから

[ファイル]-[新規]-[Javaプロジェクト]-[Javaプロジェクトを新規作成]

で、プロジェクトを作成しました。

プロジェクトを作成後、そのプロジェクトで、

[ファイル]-[新規]-[Javaクラスの作成]

を選択。

ダイアログで、スタブ

public  static main()

を作るにチェックを入れて、完了。

次のようなソースが作られました。

public class Main {

public static void main(String[] args) {

// TODO 自動生成されたメソッド・スタブ

}

}

ここに、

// TODO 自動生成されたメソッド・スタブ

System.out.print("hello") ; 

を追加して、リボンから、▶️で、実行。

コンソールウインドウに、

hello

が表示されました。

単純選択法(ソート)

 未ソートの部分から、最小値を見つけ、それを先頭にもっていく。

こんな感じのアルゴリズム。

1.未ソート部分の中から最小値を探す

2.最小値の要素と、未ソートの先頭の要素を交換する

3.未ソート部分の先頭を１つ後ろに、ずらす

4.未ソートが、１つになるまで、これを繰り返す

クロニクル ubuntu & Java でHello world

1. ソース

適当なフォルダーに、以下のようなファイル（Main1.java)を作成します。

  

class Main1 {   

   public static void main(String[] args) {    

       System.out.println("Hello world!");   

  } 

}

2.コンパイル

$ javac Main1.java 

 同じフォルダーに Main1.class ができました

3.実行

$ java Main1 

 Hello world!

が表示されました。

An Empirical Study on the Evolution of Design Smells

公開されている

An Empirical Study on the Evolution of Design Smells

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

概要

システムの改善は、時として、アーキテクチャのデグレーションを引き起こす。

そもそも存在してた設計上の問題が原因である。

このような問題を、code smellという。

この研究では、8つのソフトウェアシステムのcommitに対して、

それぞれのcommitごとに、複数のデザイン上のcode smellを発見した。

そして、発見したcode smellとリファクタリングの関係を調査した。

結果、design smellに影響されるclassは、変更が多い。

特に複数のsmellが存在するclassに多いと分かった。

smellの削除は、必ずしもリファクタリングと関連しないことが、

分かった。

イントロ

短納期への対応は、設計上の問題や、手戻りのコストが発生する場合がある。

また、将来の開発時や、保守性に問題を及ぼすことがある。

設計の問題に関しては、多くのリサーチがあり、

設計上の問題が変更こすろを押し上げるとした。

design smellは、このような問題を引き起こす兆候である。

design smellの存在は、保守に悪影響を与える。

アーキテクチャ smellは、アーキテクチャレベルでの

貧弱な設計である。

アーキテクチャ smellは、理解容易性、テスト容易性、

拡張性、再利用性などに影響を与える。

--- つづきます ---

アクセス制御の方式

1.ユーザーベース認証

認証されたユーザー事に アクセス範囲を決める。

2.任意アクセス制御

ユーザーが属するグループに対して、アクセス範囲を決める。

3.強制アクセス制御(MAC)

管理者がすべて権限を付与。オブジェクトの所有者さえ変更できない。

4.ロールベースアクセス制御

グループより柔軟に権限を割り当てる。

RAD MODELのプロセスの例

 RAD MODELのプロセスの例

1.ビジネスモデリング

・ビジネスを駆動するデータは

・誰が、どこで、何の情報をつくるのか

2.データモデリング

・オブジェクトと、オブジェクト間の関連

3.プロセスモデリング

4.アプリケーション生

・ジェネレータなどで、プログラムを生成する

5.テストとふりかえり

アルゴリズム関連の用語

ヒューリスティックス・アルゴリズム

最適解が得られる保証はないが、比較的短時間で最適化に近い解が得られる

進化計算アルゴリズム

生物の進化過程にヒントを得た最適化探索アルゴリズム
 

総当りアルゴリズム

すべての場合をためして、解を求める

近似アルゴリズム

・正解に近い解を探す。

・正解との誤差がある範囲に収まるこをと保証されているものを

　精度保証付きアルゴリズムという。

・精度の保証がないアルゴリズムを、発見的手法(ヒューリスティクス)

　と呼ぶ。

アルゴリズム あれこれ

1.探索

・線形探索法

　先頭から順に探す。

・二分探索法

　順番に並べたデータの中央との比較を繰り返す。

2.ソート

・単純選択法（選択ソート）

　最大値（最小値）を順次探して、それを先頭と交換する。

・単純交換法（バブルソート）

　隣り合うデータを交換しながら並び替える。

・単純挿入(挿入ソート）

・クイックソート

　基準のデータをもとに、分割を繰り返し、並び替える。

・マージソート

・ヒープソート

・シェルソート

3.数値計算

・エラトステネスのふるい

　素数をもとめる。

・ユークリッドの互除法

　最大公約数をもとめる。

・ガウスの消去法

　連立一次方程式を解く。

・台形公式

　定積分の近似値をもとめる。

・ダイクストラ法

　グラフで最適経路をもとめる。

・二分法

　方程式をとく。

・ニュートン法

　方程式をとく。

構造化の原則

1. 抽象化/階層化

抽象化し、階層化することで、全体を分かりやすくする。

2.分割統治

複雑な問題は、小さな問題に分割して考える。

モジュールの強度と結合度

モジュールの強度

・1つのモジュール内に存在する命令の凝縮度のこと。

・「弱いもの→強いもの」の順に、次の区分がある。強い方が良いとされる。

(1) 暗号的

複数の関係のない機能を実行する。

(2) 論理的

関連したいくつかの機能を含み、そのうち1つが外部から呼び出される。

(3) 時間的

関連の薄い機能を逐次実行する。初期処理など、実行時期が一致している。

(4) 手順的

複数の逐次的な機能を実行する。

(5) 連絡的

手順的に加えて、同じデータを処理するものをまとめる。

(6) 情報的

特定のデータを扱う機能をまとめる。

複数のエントリーポイントを持ち、1つのエントリーポイントは、

1つの機能を実行する。

(7) 機能的

すべての要素が1つの機能を実行する。

モジュールの結合度

・モジュール間の関連性の尺度。

・「強いもの→弱いもの」の順に、次の区分がある。弱い方が良いとされる。

(1) 内容結合

他のモジュール内のデータを直接参照する。

(2) 共通結合

共通のデータ構造を直接参照する。

(3) 外部結合

宣言してあるデータの参照。個々のデータ項目の参照。

データ構造がない点が、(2)と異なる。

(4) 制御結合

制御要素(スイッチ等）が、パラメータとして渡される。

(5) スタンプ結合

2つのモジュールが同じデータ構造を共有する。

(6) データ結合

2つのモジュール間のインターフェースを、

パラメータの受け渡しだけで行う。