#contents
*レポート [#uc280a63]
**感想書こうぜ！ [#v334ac1e]
コピペしやすいようにここにまとめて一人ずつ書いていきましょう。衝突をさけるために揚げる際に一声かけるとよいかと
-最近はソフトウェア開発の多人数化が多いので、将来的に自分の行うプロジェクトが複数人でプログラムを分担して作成することも出てくると思う。&br;
その点において、今回このような形で、講義で分担作業を行えたことはとても為になったと思う。(赤井)
-UMLを使うことによって、今までプログラムを書きながらやっていたことが、
順序よく効率的に設計することができることがわかった（原田）
-今回5人という比較的少人数で作業を行ったため，特にリーダーをおかず，全員の会議で進めていったのだが，それが原因で一部メンバーの作業管理がうまくいかなかったと思う．大人数での共同作業にはメンバーをしっかりコントロール出来る人間が必要不可欠であると感じた．(友田)
-複数人でシステムを作り上げることの大変さがよくわかった．こまめに連絡を取り合わないとうまくいかない部分もあり，スケジュールの調整はかなり大切だった．しかし作業自体は減って楽になるのは利点なのだと感じた．&br;
UMLは見た目で理解しやすく，それぞれがシステムを理解していくのに大いに役立ったと思う．（渡部）
-UMLで設計と言われても今まであまり実感が沸かなかったが、実際の設計作業を通じてどのように設計をするのが良いのか、またどのような利点があるかがはっきり理解できたのが収穫だった。（久松）
**まとめ草案 [#o8509151]
-関数やクラスの名前の重複や不一致を防ぐために統一させることが大変だと思う
-他人が作るモジュールとの引数はあらかじめきめておかなあかん
-納期厳守と余裕をもって計画を立てることが必須
UMLのﾒﾘｯﾄ
-視覚的にわかりやすいため、第3者でも最低限の知識があればシステムの概要がつかめる
-作図する過程で自分の考えがまとまる。
会議の重要性
-統一させなきゃならないことが多い
-人数いる方がｱｲﾃﾞｱが出る
-理解も進む
-自分のイメージに偏らない
***まとめ草案のまとめ [#d0b70c80]
まず、大人数でのシステム製作という点での問題点を考える．大人数で行うと言っても基本は分担しての個人作業であるため，個人のくせなどが顕著に出てしまう。しかし個人作業とはいえ，結合させなければならないため，共通で用いる関数やクラスの名前やモジュール間の引数や戻り値は予め決めておかなければならない．
そのために、事前に綿密に会議を行っておくことが必要不可欠である．会議をすることによってメンバー全員の理解を助けることや多種多様なアイデアを取り入れることもでき，個人のイメージに偏らないという利点も得られる．また，共同作業である以上，個人のミスが全員にかかることも考えられる．そのため余裕をもって開発スケジュールをたて，全員がそのスケジュールを守ることが必須である．
次にUMLのメリットについて考える．UMLはユーザの要求からユーザがそのソフトウェアを使用するシナリオを作成するところからスタートする．このときユーザの立場になって使い方や操作感覚をシミュレーションするため，ユーザをおいてけぼりにした独りよがりなシステムになりにくい．
さらに、システムの流れや動きを把握していないと図を書くことは不可能であることから製作者の考えをまとめるという利点も得られる．また，図式化することにより視覚的に理解できるようになっているため，最低限の知識さえあればシステムの概要を把握することが出来る．これは途中からプロジェクトに参加した場合などに有効だと考えられる．
**考察草案 [#tb6d44dc]
ﾓｼﾞｭｰﾙを作成する。ｱﾙｺﾞﾘｽﾞﾐは〜〜〜を予定しているとかの方向で書こう！
-其の一&br;
Tabと半角スペースに変換するモジュールを作成する。あたえられた引数によって作業をわけ、スペースをTabに変える場合とTabをスペースに変える場合にわけるとする。&br;
プログラムはソースコードをよみとり、指定された個数の半角スペースのならびおよびTabを検出し、指定された形へ置換する。これをソースの末尾まで繰り返す。&br;
最後まで変換が終わったらファイル管理のクラスを呼び出してファイルを上書き保存して終了するようにする。
-作業の流れ&br;
モジュール作成→モジュールテスト→結合→結合テスト→システム全体のテスト→第3者による評価実験
-単体テスト
--ファイル読み込みで、テキスト形式以外はエラーを返す
--ソースの中に故意に使われない記号を紛れ込ませておくとか
--普通のデータもいれておいて、ちゃんと変換できているかチェック
-課題
--ﾍﾞｸﾄﾙとかﾏﾄﾘｯｸｽの中括弧（中括弧内にｾﾐｺﾛﾝがあるかないかで判定？）
--関数はmain{って書きたいけどforは改行したいなど
--switchのcaseのインデント
--1文で中括弧のない場合&br;
ただこのような要求もあるかもしれないのでサポートする必要がある。関数、構造体for･whileなどそれぞれの場合毎にユーザに改行するかいなかと選択してもらうという手段もあるが、そうするとユーザの操作がくどくなってしまう。この問題を解決する方法は現在模索中である。
-何を受け渡ししてるのか&br;
メイン→ファイル管理（バックアップ、上書き）はファイル名&br;
ファイル管理→メインはバックアップ、上書きは正否だけ&br;
オープンはソースの中身を各処理へ&br;
各処理はソースの中身を受けとる、そして変換したソースを返す&br;
-他のテストについて簡単に
--結合テストはソースの受け渡しがうまくいってるかを途中に出力をいれて確認
--システムテストは全ての入力パターンを試し、システム全体を確認する
--バグや改良点が見つかったら直して回帰テスト
--最後に第3者によるテストによって見落と、操作感覚、PCのスペック依存などの確認を行う
-設定の保存について&br;
1回で見切りを付けられない限りは普通は複数回使用することが考えられる&br;
その時いちいち設定をやり直すのはとても面倒&br;
設定ファイルに保存して、次回起動時にはそれを読んでGOサインだけだせばいい状況にしたい。&br;
でも今更図を書き直したりするのは無理があるので課題残しで&br;
無視してもいいけど一応検討の余地はあると思います(By川獺)
**クラス [#xd907c8a]
メイン（GUI、処理）、ファイル管理（読み込み、バックアップ）、各処理で１つずつ
ファイル管理&br;
｜&br;
ユーザーメイン&br;
／ ｜ ＼&br;
括弧 空白 多段インデント
必要とされるクラスは５つ。&br;
メインメニューはGUL部分の生成、処理選択などの入力欄の作成と引数の受け渡しを行う。&br;
すべての処理はソースファイルの書き換えを行うので、ファイル管理のクラスをつくって指定されたファイルを開き、バックアップの作成と上書き保存を担う。&br;
コードの変換部分はTabと半角スペースの変換、括弧の整形、インデント調節の３つをそれぞれ分けて作業をさせる。それぞれ開かれたファイルのコードを読みこみ、検索と変換をかける。&br;
**シナリオ草案 [#u4970e90]
-プログラマが整形対象であるソースを選ぶ（単or複）
-整形メニューを開く
メニュー→ファイルを呼び出す（「〜.bak,〜.old」保存）→ソースを書き換える→出力（エラー報告、設定状況）
入力：１．単体ファイル ２．複数ファイル ３．フォルダ&br;
処理:ａ．Tab←→空白 ｂ．括弧 c．インデント&br;
後処理：エラーの有無（括弧の数の不一致、ファイル形式が違う）&br;
（バックアップ作成、何を変更したかの報告も入る？）
入力→処理（複数可）→後処理を組み合わせで書く
-赤井 ２→ｃ
-友田 ３→ALL
-原田 ３→ｂ→エラー有り
-久松 &br;
-渡部 1→ａ
**必要事項 [#mde741a4]
-シナリオ（各自1個ずつ）
-ユースケース図（久松）
-クラス図（渡部）
-モデル
--アクティビティ図（原田）
--シーケンス図（友田）
-サンプル（赤井）
8/3日までに仕上げる&br;
各自でき次第ここにup
それ以降にレポート作成（考察、まとめ、感想）（締め切り8/4）
**章分け [#p6c47991]
これであってる？
+目的
+仕様
++シナリオ
++ユースケース図
++クラス図
++モデル
+++アクティビティ図
+++シーケンス図
+実装
++サンプル
+考察
+まとめ
+感想
*仕様書案 [#z3fde9bf]
**改良案 [#z6260123]
主な目的はC言語のソースコードを成型することである
基本仕様
-成型する上で、人によって左側をスペース複数で開ける人とtabキーをつかって開ける人がいるので、それをどちらかに統一する。その際どちらを基準にするかはオプションで決められるようにする。
-｛｝や（）の位置を調節して、文末に来る場合と文頭に来る場合のどちらになるかを統一する。どちらを基準にするかはオプションで決定。
-スペースおよびtabを用いてインデントを調節し、どこまでが一くくりなのかをわかりやすい形にする。
-元の形がわかるようにバックアップのデータを取っておく。
-変換するファイルの入力は3通りある。
++フォルダ単位
++ファイル複数指定
++ファイル単体
-変換に失敗したときや、読み込みに失敗したときはエラーを吐き出して停止する。
-GUIになるように。コマンドラインからの実行ではなく、使いやすい形にする。
-文字数が多く画面に収まらない場合は、途中で改行を入れて見やすくする。ただし優先度は低いので実装が難しい場合は後回し。
**チラシの裏 [#j6c79cb0]
-ソースコード整形
-C言語限定
-空白←→タブ変換、量
-かっこの位置を整列する
-↑オプションは指定
-バックアップを残す
-ファイルの入力は（フォルダ単位／ファイル複数／ファイル単体）
-多段インデントをちゃんとする
-（行数オーバーの時は改行？）
-エラーを吐く
-設定は（できれば）GUI、コマンドラインは×
*コメント欄 [#da2d5674]
-コメントテスト -- [[久松]] &new{2005-07-29 (金) 17:22:19};
-なんかあったらここに書いてちょ -- [[久松]] &new{2005-07-29 (金) 17:22:30};
-オブジェクトってユーザ、メニュー画面、ファイル(フォルダ)以外って何があると思う？括弧とかはクラスだよね？ -- [[友田]] &new{2005-08-02 (火) 04:51:09};
-こんな基本的なことを今更聞いてゴメンナサイ -- [[友田]] &new{2005-08-02 (火) 04:51:43};
-ユースケース図アップ 多分まだまだ足りないけどとりあえず -- [[久松]] &new{2005-08-04 (木) 12:31:25};
-ソフトウェア工学.doc 現在第3版 ほとんとコピペ -- [[久松]] &new{2005-08-04 (木) 20:24:59};
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
