- - PR -
UMLを用いた開発について
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-06-03 16:12
これは必須ですね。 いくら便利でもライセンスがない人は紙で見るだけ、では困ります。 | ||||||||||||||||
|
投稿日時: 2002-06-03 16:28
「ソースの中にコメントとして何を書くべきか？」は他でも議論されていると思いますが、『推奨されるコーディングをはずしている時（理由があって、似た処理なのに他と手順が違うとか）はその理由を書く』というのは個人的には欲しいですね。 小手先の技に走って他の人からわかりにくくなるのは避けておきたいところです。 | ||||||||||||||||
|
投稿日時: 2002-06-03 18:30
artonさんの案、XPも取り入れ、技術者としての本音が出てて、現実的だと思いました。 でも逆に、artonさんでもUMLをこれ位しか活用出来ないという、現実が寂しいですよね！ 最近だと、リファクタリングにも対応したＵＭＬベースのツールが出て来てるようです。 私は、技術者がメインで使ってる環境と別環境ではなく、一体でそのソースをベースとして、足りない部分を補完してくれるツールを期待したいと思います。（低価格で！） 私も、ソースが全てだと思います！ 真に役立つＵＭＬツールは、顧客・開発者全てに利益をもたらすと思います。 そういう意味では、ＵＭＬツールは、日本の国レベルで取り組んでも良い対象かも知れませんね！ | ||||||||||||||||
|
投稿日時: 2002-06-03 18:54
「UML」
これが、最終形態か？ この理論や考え方は、新しく無い。 非常に長い間、色々なものが出ては消え、出ては消え、 また、改良され、商品化され、実用に耐えず、 開発した企業その物が、あっちこっちのグループの傘下に入ったり、移動したり、 もしくは完全に失敗したりを繰り返し現時点で標準と言われる 「UML」 スタートは、フォーマットの決まった、英語など、日本語の物も１つか２つあったと 思う。 厳しい制限を設けた単語と語彙で、設計書を作り。。。 段階的に落としていき、 自動ソース生成、が試みられ、 グラフィックからソースに落とす物も存在したが、 結局実用に耐えなかった。 「UML」 に、どこまでの機能を望むか？ あと、ソースに書くコメントですけど、 コメントは必衰ですが、 コメントがあってソースがあるのでは無く、 ソースがあってコメントがある。 これは、当たり前と思うかもしれませんけど。 設計段階と、コーディング段階で、要求仕様にずれが発生した場合、 すでに、デバッグが終わっているソースに手を加えなければならない 場合も現実には存在すること。 もしくは、総合テスト段階で、問題が発生したり、 全体では大きなシステム構築を、最近の傾向として、 細かく数回に分けて、開発になったとき、 最初に開発し、運用されているものが、最終段階まで、 現実に即しているとは限らない。 顧客の要望はこういう形態ほど、使えば使うほど、要望が増える。 もしくは、仕様だったのが、仕様でなく、言葉の勘違い、行き違いから 発生した初期要求仕様でのすり合わせが完全に行っていないか、勘違いが そのまま続いてしまう。 そして、それを解決するには。。。 ソースに無理な改造をすれば、コメントは意味をなさなくなる。 なんで、こんな事を書いたかと言うと、この現象は、 アメリカやドイツやイギリスに比べ、 フランス、アジア、日本、特に、日本などは顕著に、日本語という 特性から、起きやすい。 その為に、間違いの無い意思疎通のための、標準的な要求仕様段階から、 詳細設計までの、もしくは、概要設計までの 専用の何らかの表現方法が必要と思うんですが。 この部分に 「UML」 を、当てはめるのは、どう思うでしょうか？ 「UML」 に 過剰な期待はしない。 意思疎通のための 「共通表現方法」 として、捕らえると言う考え方は、 どう思われますか？ 実際に、ソースに落とすのは、やはり、従来と同じくコーディングした 方がいいのでは？ どう思われるでしょうか？ 色々と、賛否両論、聞かせて欲しいんですが。。。 | ||||||||||||||||
|
投稿日時: 2002-06-03 20:26
えーと、ちょっとドキュメンテーションコメントに対する誤解がもしかしたらあるかも知れないので、念のため、
http://jakarta.apache.org/tomcat/tomcat-4.0-doc/servletapi/index.html というのが例ですが、ソースファイル中に特殊なキーワードと共に埋め込んだコメントを取り出してドキュメント化する仕組みで、JavaとC#にはツールが提供されています。 通常は、クラス、メソッド、フィールド単位に記述します。
というのは、多分コードの行間に記述されることが多いいわゆるコメントだと思いますが（誤解していたらすみません）、そうではなく（僕は、ビジネスルール以外の行間コメントには反対です。除くアセンブラ）、あくまでもAPI仕様書であり、実装仕様書であるコメントです。 実装仕様書とソースが分離していると、開発の最初の段階では仕様書ライターとソース実装者はたいてい異なるので構わないのですが、メンテナンス段階に入ると、仕様書ライターとソース実装者がイコールになる場合がわりと多いので、最初から一緒にしてしまえという発想です。 つまり、放っておけば仕様書とソースに乖離が出るし、どうせプログラマはちゃんと仕様書メンテしなそうだから、ソース1本にしとけばできる可能性があるのでは？ ということです。（オリジナルのhttp://java.sun.com/j2se/javadoc/writingdoccomments/index.htmlでは、微妙に意味合いは異なりますし、詳細仕様書を兼ねろとはどこにも出てません。念のため） で、この仕様書＝ソースで丸ごとソース管理するのが良いかも、と考えているんですが。 さらに追加しておくと、実装仕様書といっても同一ファイルの直下にソースそのものが来るわけですから、相当ゆるい形式にならざるを得ないとも考えています。 以下余談： どこでかは忘れましたが、XPではドキュメンテーションコメントはテストケースに書くべきで、ソースに書いてはいかんのでは？ という意見を読んだことがあります。入出力の記述という意味では、もっともなのですが、それはいささか過激ではないかと思うんですがどうでしょう。 #全然、UMLではなくなってしまいましたが…… | ||||||||||||||||
|
投稿日時: 2002-06-03 20:41
大して広まらないうちに、仕様ばかりが膨れていくという悪いサイクルにUMLは入っているような気がしないでもないです（さすがにすべてを知る気にはなれないです）。ユースケース図、モデル図、協調図、クラス図、配置図くらいだとちょうど良い感じなのですが（これでは帯に短いかぁ）。
確かにそうですね。理想を言えば、複数開発者で（特にJavaだとクラス＝ソースだったりするので）シェアしながらかつバージョン管理ができて、ソースとクラス図については行き来ができるのがベストだと思います。こうなると基本的にはテキストベースで差分が見えないと辛いですが。 | ||||||||||||||||
|
投稿日時: 2002-06-03 22:00
もう、当たり前でしょうがないんでしょうけど？
C#は、マイクロソフト製品としておいて Javaなんですけど？ これ、 ＞ソースファイル中に特殊なキーワードと共に埋め込んだコメントを取り出して ＞ドキュメント化する仕組みで、JavaとC#にはツールが提供されています。 UNIX系列やLinux系列にも、そういうツールが存在するんでしょうか？ あくまでも、デファクトスタンダードではなく、純粋なるスタンダード（標準規格） としては、現状どういう発表があるんでしょう？ OS間で、特に、UNIX,Linux関係と、どの程度、ソース互換があるんでしょう？ | ||||||||||||||||
|
投稿日時: 2002-06-03 22:28
ごめんなさい、誤解してました。 以下、引用が前後しますが、
という考え自体は賛成なのですが、
ちゃんと仕事しないプログラマにあわせて、というのは本末転倒でしょう。 「仕様書ライター」が「ソース実装者」より偉いとは限りませんが、（以下省略）。
そもそもこのスレッド自体がそうなのでOKですよ。 
ところでartonさんに質問なのですが、JAVADOCでAPI仕様書を作るのはいいとして、ユーザーインターフェースそのもののクラスとなると言われてる方法で仕様書として十分なものができるのでしょうか？（そもそもJAVAが良くわかってないかも知れませんが） | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。