04．はじめてスマホアプリを作ってみた（設計フェーズ）【 Android / Xamarin.Forms 】

記事の概要

こちらの一覧の４つ目、「設計フェーズ（どうやって作るか）」の記事となります。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）

こちらでインストールできます
※アンドロイド版のみです。iPhoneユーザの方すみません。

全７回に分割して書いていますが長いので、ダイジェストで読みたい方はこちらの記事をご覧ください。

はじめてのスマホアプリ開発 設計フェーズ

スマホアプリの設計を開始する

前回は、スマホアプリ開発に必要なフレームワークや言語、その他サービスを決めていく過程について書きました。

ここまでで、「どんなアプリを作るか」「要件をどうするか」「どの技術を使うか」が決まったので、いよいよ設計作業に着手していきます。

そんなに機能の多いアプリではないので「闇雲にコードを書き始める」ことも、ひとつの方法かもしれません。

しかしプログラムを書いていく過程で、どうしてもバグを埋め込んでいくことになります。
絶対に混入します。
絶対に。

これまでの遷移図やデザインでは見つけやすい不具合も、プログラムを量産していくとよっぽどしっかりしたテストを準備できていない限り見つかりにくくなります。

準備不足でプログラミングをしていると、余計なコードを書いてしまう確率は上がります。

できる限り設計作業を進め、開発ツールを立ち上げているときはコーディングに専念できるように準備を進めていきたいと思います。

全体のアーキテクチャを考える

この時点でわかっていることは、「画面構成」「画面遷移」「各種機能」です。
これを設計に落とし込んでいくにはどうすればいいでしょうか。

今回の作業と並行していくつかの書籍やウェブサイトを読みました。
その中で設計作業に特に役立ったのが以下となります。

参考にしたウェブサイト

• Peacock-ANDERSON
  https://school.anderson02.com/

参考にした書籍

• オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES)
• ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
• Clean Architecture　達人に学ぶソフトウェアの構造と設計

各書籍等の内容についてはこちらの記事でもう少し詳しく書いています。

一読してすべてが理解できたわけではありません。

今回の作業の工程で必要な情報がどの本のどこに書いてありそうかを把握して、その都度、ウェブ検索で周辺情報を広いながら活用しました。

なぜシステムアーキテクチャを理解しておきたかったか

いざプログラミングをするとなった場合、どのファイルにどんなコードを書けばいいか迷ったりしませんか。

初心者にとって、いくつもに分けられたソースファイルの構造などは理解し難いモノがあります。

作りたいアプリの要件を、プログラムの構造に落とし込む作業を助けてくれると思ったのです。

「ドメイン駆動開発」を参考にする

今回のアプリは非常に規模の小さいモノなのでオーバースペックな気もしますが、「ドメイン駆動開発」を特に参考にしました。

初心者のわたしが正しいドメイン駆動開発を実践できたわけではありませんが、とても助けになったと思います。

「睡眠記録を保存する」と一口に言っても、いざ設計を考え始めると、

• その日の記録対象の睡眠時間の範囲はどうするか
• 起床時間が就寝時間より過去だとおかしい
• 重複した時間帯を記録させたくない

などいくつもの必要なルールが思い浮かびます。

要件をプログラムでどう表現すればいいか

具体的に言うと、どのファイルに書けばいいか迷うわけです。
上記の参考にした書籍では、こういったコア・ルールは「ドメイン」に書こうと説明されています。

今回、結果的に二つのデータベースを切り替える機能を実装しました。
では、データベースとやり取りする処理はどこに書けばいいか。
「インフラストラクチャ」に書こうと説明されています。

こんな具合に、作りたいアプリの各機能やルールなどをプログラミンでどう表現していくのが良いかをシステムアーキテクチャの理解が助けてくれます。

アーキテクチャを考慮するメリット

また、「ドメイン駆動開発」や「Clean Architecture」を参考に設計をしておくことで、後々のメンテナンスを容易にしてくれるメリットもあります。

現段階では非常に小規模なアプリですが、いずれ分析などの機能追加をする野望があります。
理解できた範囲ではありますが、今回構築したこの設計は、のちのちわたしを助けてくれると思うのです。

ただ最初はやはり難しい

本に書かれていることも、実際に壁にぶつかって初めてその必要性を実感できたりします。

一行もコードを書かずに設計を洗練させるなんて初心者にはムズイです。

ですから、理解できなかったとしてもそこで手を止めず、何度でもイチから作り直す気持ちでやってみるといいかもしれません。

実際わたしは、わからないまま進めて「そういうことか！」となり、使えるコードは流用してイチから作り直すことを何度かしています。

これを繰り返し、納得のいく設計に近づけていきました。

実際に作った設計内容（コンポーネント図）

以下は、今回のアプリを構成するコンポーネント図です。

「Visual Studio」を使用しているので、図の「Domain」などは独立した「プロジェクト」として構成しています。

コンポーネント図

Domain

睡眠記録のドメインモデル、何時から何時までを当日分とするとか、二度寝は記録できるけど重複した時間帯は保存しないといったビジネスルール、Repositoryインターフェイスなどを実装しています。

Application

Xamarin側のCoreと、ドメインのインターフェイスを介したInfrastructureとのやり取りを中継しています。

Core

Xamarin Formsのcommonプロジェクトです。Android、iOSの共通部分を実装しています。

Android・iOS

各プラットフォームに依存する部分を実装しています。

Infrastructure

RealmとCosomosDBとのやり取りを実装しています。
ユーザがログインしていればCosmosDB、そうでなければRealmに接続します。
RealmはSQLiteのようなローカルDBを提供してくれる製品です。

Tests

ユニットテストをここに書いています。
テスト対象のプロジェクト毎にフォルダを作り、その中にテストファイルを置いています。

「Visual Studio」の話で恐縮ですが、各プロジェクトを構成し、参照を貼る方法は以下の記事が参考になりました。

各プロジェクト（コンポーネント）の中身を考える

これでアプリ全体の骨格ができました。
次は、各プロジェクトの中身を考えていきます。

本来であれば「 UML」などを扱えるツールなどでドキュメントを作成しながら設計を進めていくべきかと思います。
しかし、ドキュメントをひとつひとつ作成することはできれば避けたいものです。

最終的なアウトプットはできるだけ自動生成できるツールを頼ります。

まずは試行錯誤

手順としては、まず紙とペン、ツールでも何でもいいのでどのような「クラス」を展開していくかを考えました。

ちなみにこの試行錯誤は「drawio」というツールを使いました。
Web版ツールとして公開されていますし、Microsoft Store から入手することもできます。

主に考えていくことは、クラス名、そのクラスの目的、実装するプロパティやメソッドもできる範囲で考えていきます。

一気に全体を行うのはキツイので、まずは Domainプロジェクト を仕上げました。

ここでは他のプロジェクトで使用するインターフェイスなども考えていくことになるので、アプリ全体のイメージが浮かんできます。

そして清書は実際のソースファイルに

ある程度まとまったら、実際にVisual Studioでフォルダを構成し、クラスファイルを作成していきます。

そして、drawioではメモ書きだった内容を、クラス、メソッド、プロパティに「XMLコメント」として、しっかり書きます。

「XMLコメント」は、「docfx」というツールでHTMLファイルに出力することができます。
DocFXを使ってC#のソースコードからAPIのドキュメントを作成
DocFX
コマンドラインツールですが、非常に便利でソリューション全体をひとつのウェブサイトに出力することができます。

また「Visual Studio」の機能として、クラス図を出力することもできます。
Visual Studioでクラスのコードからクラス図を作る

Enterprise版であれば依存関係図も自動で作成できるのですよね。ほしいけど高い。

この他に、複雑な処理を設計するのにシーケンス図を書いたりしましたが、その際は「drawio」で作成しました。

Visual Studioは静的解析が走るのでエラーや警告が出まくります。
ですがここでの目的はあくまでクラス構成、クラスやメソッド等の命名など骨組みを組み上げていくことなので全無視で仕上げました。
エラー等は実装段階できっちり潰していきます。

まとめ

実装時には、実装方法に頭を使いたいと思います。
このぐらい決まれば、どうにか専念できそうです。

いろいろツール名をあげましたが、使い方などは今回の一連とは別に記事を書きたいと思います。

前段でも書きましたが、一度も実装したことがないものを机上の設計でまとめあげるのはとても難しいです。

わたしはサンドバッグのような仮プロジェクトをボコボコ作っては試し、あまたのプロジェクトの屍を築きながら作業を進めてきました。

またもや長文にお付き合いいただきありがとうございます。

次回は、開発フェーズ（実際に作りはじめる）についてまとめます。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）