|
マインドマップで文章を整理する 本記事のはじめにも触れましたが、Mame Talkの開発中にAndroidのバージョンが上がり大量の仕様変更がありました。このバージョンアップに伴いAndroidの公式サイトでは「Android SDK M5 Release - API Changes Overview」というページが公開され変更点や対応方法などがまとめられていました。しかし文章の量が多く、しかも英語で書かれているため理解するのに苦労しました。 はじめのうちは原文を読みならアプリケーションの修正を進めていたのですが、ところどころプログラムを動かしてみるまで意味がわかない部分があったり、単語の意味を忘れてしまったりと、非常に効率が悪かったのです。しかし、マインドマップで文章を整理し、変更点をまとめることでスムーズに修正が進みました(図3)。 図3のマインドマップと原文を見比べてみるとマインドマップのほうがわかりやすいのではないでしょうか。日本人には苦手な英語の文章もマインドマップを使えば比較的楽に理解できるようになります。 マインドマップにも向き不向きがある! 仕様の整理やアプリケーションの設計にUMLを使うことも考えられたと思います。しかし筆者は仕様の整理にUMLを使いませんでした。それはUMLで描くにはまだ仕様が厳密に決まっておらず何を書いていいかわからなかったからです。 UMLの場合、まずどの図を使うかを決める、必要なクラス候補を挙げて操作を洗い出す、など図を描く前に考えることが結構あります。アプリケーションの仕様を決めている段階は自分の頭の中にあるイメージが厳密でない場合が多く、筆者のように何を描いていいかわからなくなることがあります。そのような時にはマインドマップで一度頭の中を整理し、曖昧さを取ってやることが重要です。 またUMLの場合、クラスや操作を決めていくので発想がどうしてもシステム寄りになってしまいます。マインドマップであればシステム的なことを気にせずアプリケーションの振る舞いに焦点をあてて自由に描くことができます。そういった理由から仕様を決める段階ではUMLよりもマインドマップのほうが向いていると言えるでしょう。 では設計作業をすべてマインドマップでやればうまく行くのでしょうか。それは違います。万能に思えるマインドマップにも不向きなことがあります。マインドマップはクラス同士の関連を表現することが難しく、さらに図が静的構造しか表せないため、プログラムの動きを時系列で把握することが困難です。その点UMLは厳密にプログラムの構造と振る舞いを表現することができるので、マインドマップの欠点をうまく補ってくれます。 プログラムが複雑になればなるほどUMLを使ってプログラムの構造と振る舞いを理解することが重要になります。次回はクラス図を使ってプログラムの構造を整理する方法を紹介します。 |
||||||||||
|
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||


