設計思想/ソフトウェア工学(UML, デザパタetc) [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
・要求設計、概念設計、論理設計、物理設計までを扱う範囲とします。 設計なんで実装の話は原則禁止 どの言語でも通用する話をするべき >>4 設計の話なんで、ExcelとかSQLとか言う話はいらない。 抽象化して書いてくれ いや俺が書いてあげよう。ExcelやSQLという言葉を消すだけだが ・「マイグレーションファイルに記述した定義から いろんなデータベースにスキーマと初期データを自動生成する。 このフレームワークは初期データファイルから データの流し込みを行ってくれる スキーマや制約も出来る限り 頑張って設定してくれる。(わからない場合デフォルトの名前とか が入るようになる。) オプション指定機能が搭載されていて、 オプション次第で多くのDBMSに対応できる。 ER図とかの自動生成機能も存在する」 つまりRailsのようなものだ。 Railsを設計してくれという話だ。 >>9 そこに出てくるExcel・SQL・DBは みんな要件レベルの話で実装の話じゃないよ つまりは>>4 はActiveRecordの設計がどうなっているか? ORMとはどのような設計になっているかという話がしたいということだろう。 ORMとはデータベースをオブジェクトにマッピングしてくれるものだ。 というのはよく言われる簡単な説明の一つだな。 まず二次元のデータベースっていうのは慣れると単純なので ある意味楽ではあるが、現実世界は二次元のデータには収まらない 初心者が勘違いしてしまうのはORMは単なるSQL生成ツールだと 思ってしまうこと。まあそれは本当の初心者だろうが、 ORMは複数のテーブルがあってそれぞれがつながってる データベース全体をオブジェクトの形で表現するもの。 テーブル=モデルと考えてしまうと、ある地点で行き詰まってしまう。 データベース=モデル群と考えるのが正解。 データベースに入っているデータをいろんな視点(=モデル)から 見ることができるようにするのがORM だからORMを使う時にモデルとモデルのつながりの定義を書くのは必須なのである (もちろんログや設定のようなつながりを持たないモデルもあるにはあるが) >>11 設計の話なんで要件の話はいらない。 設計の話をしましょう。 ActiveRecordとかね ActiveRecordはRailsが有名になったせいで Rails特有のライブラリや概念だと勘違いしている人も いるかもしれないがそれは違う。 ぐぐればすぐに分かることだが http://www.techscore.com/tech/Ruby/Rails/other/designpattern/1/ > 1. Active Recordパターンとは? > > Martin Fowler氏の Patterns of Enterprise Application Architecture (邦訳)で > 解説されているデザインパターンのひとつで、以下のように解説されています。 > > データベーステーブルまたはビューの行をラップし、データベースアクセスを > カプセル化してデータにドメインロジックを追加するオブジェクト 日本語訳は残念との噂が高いが、この本のこと エンタープライズアプリケーションアーキテクチャパターン https://www.amazon.co.jp/dp/B01B5MX2O2 なのでActiveRecordパターンの話は あきらかに設計思想の話であると明確にしておこう >>10 いいやそれは違う。 マイグレーションファイル書かないとだめじゃん。 SQLという文言は排除してもいいがExcelは排除したくない。 「IT全然知らない人がつくった.xlsxファイルを、データベースに入れたい」 「それと同時にデータベースをつくってくれる呪文」も手に入れたい。 RailsとかORMとか ActiveRecordとかもっと詳細化された概念じゃん。 ActiveRecordパターン等のパーシステンス層アーキテクチャパターン には次のようなものが有る http://otndnld.oracle.co.jp/columns/arai-semi/data_access/2/ > Table Data Gateway > Row Data Gateway > Active Record > Data Mapper >>15 > Excelは排除したくない。 お前の都合は知らん。 一番シンプルでわかりやすく強力な手段を選ぶべき 例えば、booleanと書けばいいのに真偽値と日本語で書くようなもの。 not null と書けばいいのに必須と日本語で書くようなことに意味はない その考えで行くとExcelは排除すべきという結論になる そのことを説明してもいいが、そもそも設計の話とは無関係なので Excelの話はここでもう終わり お前風言うのであれば 「Excelは排除したい」だ。このスレから 仕様が確定してれば設計なんて猿でもできる 仕様が不確定な問題を設計までもってくる馬鹿がいるとその開発は失敗と思っていい 一人で設計とは関係ないエクセルがーって 話をしたいならどうぞご勝手にとしか言うつもりはない。 ただ設計思想とは全く関係ないということだ。 だから設計思想の話をしたいと思ってる人は 俺を始め、エクセルの話は誰もしないということは受け入れろ。 >>18 > 仕様が確定してれば設計なんて猿でもできる それができる猿は見たこと無いので 説得力ゼロだよ。 設計思想の話に戻ろう といっても俺が何やら言うよりもまずはコピペでいいあろう。 設計思想の話について、何か意見があればどうぞということだ。 Active Record 3つ目はActive Recordです。一言で言うと「データベースのテーブル/ビューの 1つの行をラップしたオブジェクトで、データアクセスロジックやドメインロジックを カプセル化したオブジェクトとして実装」といえるかと思います。 Active Recordは、それ自身にドメインロジックを含むという点でドメイン層の Domain Modelパターンとデータベースのテーブルのレコードを表すという点で パーシステンス層のRow Data Gatewayパターンに良く似ています。 まず、Domain Modelと似ているという点ですが、Active Record自体が Domain Objectと成り得るのですが、本当?のDomain Objectと異なる点は、 Active Recordはテーブルの構造を元にして基本的にテーブルの列の表現として設計される点です。 一方、Domain Objectは、テーブルの構造に関係なく、オブジェクト指向のドメイン分析の結果抽出されます。 例えば、前編で説明したDomain Modelでは、Strategyパターンを利用しているものの、 BIDテーブルに対応したBidクラス、Itemテーブルに対応したItemクラス、 SALEテーブルに対応したSaleクラスとテーブルとクラスがほぼ一対一になっていますが、 ドメインオブジェクトの設計によっては同じテーブル構造のまま、Itemを抽象クラスとして用意して、 そのItemを継承したBookやComputerなどの具象クラスを作成する様な継承関係を実装するかもしれません。 その場合、それら継承関係をItemテーブルという1つのテーブルに格納しなければならないかも知れません。 つまり、Domain Modelが複雑になればなるほど、両者の違いは明確になってきます。 そもそもドメイン層とパーシステンス層という全く役割の異なった層のパターンですので違うのが当たり前ですが・・・ あと、Row Data Gatewayと似ているという点ですが、これは単純にActive Recordがドメインロジックを含むという点かと思われます。 Active Recordパターンのコードは、Row Data Gatewayとほぼ同じです。異なる点は、 それ自身にドメインロジックが含まれるという点ですので今回は省略します。 パーシステンス層アーキテクチャパターンの選択 それでは、どのパーシステンス層のアーキテクチャパターンを選択すべきでしょうか? これは、ドメイン層のアーキテクチャパターンの選択に大きく依存します。PoEAAでは、以下の様な組み合が考えられるとしています。 ドメイン層アーキテクチャパターン パーシステンス層アーキテクチャパターン Transaction Scriptパターン Row Data Gatewayパターン Table Data Gatewayパターン Domain Modelパターン Active Recordパターン Data Mapperパターン Table Moduleパターン Table Data Gatewayパターン ドメイン層とパーシステンス層はどの様な組み合わせでもかまいませんが、 より合わせやすいパターンは上記の様な組み合わせといっています。 また、少し視点を変えて各アーキテクチャパターンとシステムの論理的な階層の依存関係を表すと以下のように成るかと思われます。 【図】パーシステンス層/ドメイン層アーキテクチャパターンの依存関係 かなり抽象的かつ感覚的な図ですので、大体の感触をつかんでいただければ良いのですが、 1つ言えることは、システムの論理的な階層である、ドメイン層とパーシステンス層は、 其々異なる役割を持った層ですので、お互いに依存が少ないほうが好ましいと思われます。 その点で言うとDomain ModelとData Mapperがお互いの層で依存関係が少なく済みます。 >>22 に自己レス パターンはぶっちゃけどれもまともに使っていれば悪くないんだろうけど 結局は使うフレームワークによるよな。 ウェブのシステムは単純なのが多いから トランザクションスクリプトパターン使って テーブルデータゲートウェイかな? SQLを生成してくれるライブラリで十分だと思っているけど、 Rails使ってみるとアクティブレコードパターンよく出来てるんだよな。 これぐらい作り込まれていれば、ドメインモデルパターンもやる気になる (流石に貧弱なフレームワークでドメインモデルは大変すぎた) わかった、Excelはゴリ押しするのはやめよう。 ただ、なんでExcelがいいかっていうと、 既存でExcelで格納されたデータってたくさんあるだろ、 この「既存の表を情報処理できるように整理したい」と いうのが目的。 スプレッドシートでざっと「DBのテーブルっぽい表」を つくって、今回開発するシステムにその「表」を見て推測させて それっぽい構造をつくってもらいたい。 あとはそっからSQLが分かる人なら、DBいじって手直しできればいいな~と そういう話です。Excelも固有名詞だからゴリ押ししたのは済まなかった。 >>14 Active Recordで「パターン」なの!? そりゃ知らなかったぜ。 >>24 エクセルはただファイルフォーマットにすぎない。 設計思想とは何の関係もない。 ファイルフォーマットとしてみれば 無駄に重く二次元に縛られてるから柔軟性がない。 YAML形式のほうが遥かに可読性が高くて 柔軟性が有るファイルフォーマット ってかファイルフォーマットの話はいらない。 >>25 Martin Fowler氏の Patterns of Enterprise Application Architecture(通称PoEAA)で 紹介されているデザインパターンの一つのアクティブレコードパターンを 実装したのがRailsのActiveRecord 時系列的に見ればパターンとして紹介された後にRailsがつくられてる なるほど。 >>26 .csvに書き出せばいけるやん? 最初からそう言わなかった俺が悪いが。 このお題は良くないかな、きっと構文解析必要だよね、 それって設計はあまり関係なくなってくるよな。 設計って何? 業務? プログラム? なんの設計を考えるの? こまったwwwww代わりの要求を考えたが出て来ないわwww だれか要求出せる人お題考えてくれwwwww >>28 > .csvに書き出せばいけるやん? だからファイルフォーマットの話はどうでもいいの 設計とは無関係 無関係だが言っておくとYAMLの方が見やすい CSVなんてインデントすらまともにできないだろ 階層構造のデータも作れない >>30 設計思想の話で要求とか関係ないと言ってる。 設計思想の話をするならば、なぜあのフレームワークは こういう設計になってるのか、その思想が知りたい とかそういう話 >>31 そうだな。 それを「データから」推測して構造再構築できないかな。 たとえば、"太郎"が見つかったら -> 「漢字が使われている(Unicode)」である ->「東アジアらへんの人名っぽい」とか (少なくととも"ASSDFEWHE"のようなランダムなトークンではなさそうとか) -"2017/09/30"を読んだら->「日付だ」とか。 型が特定できたら、開発するシステムがある程度自分なりの考え方で 整理整頓して正規化して、再構築してくれる。 あと、重要な前提として元データの「完全再現移植」は目指さない。 っていうの後付だけどつけるわ。 ずっと実装の話になってる 実装だと分かるから言いたくなる いかに設計が難しいか分かるな >> 34 まさにそれ、ほんとすみません。 こうしよう。 >>40 以降に書かれた最初に「お題」として投稿されたものに対して 議論しよう。 どういう方針で実装するか考えことが設計だろうに。 実装とも言語とも切り離して考えることが何の役に立つのだ。 この状態を取りまとめてくれる 有能なプロマネ兄貴が来るのを待つしか無いな。 >>4 の要件そう悪くなかったのに変なのに流されるからだよ >>10 がクソ「いろんな」←はぁ? 社会人ですか?w お里が知れるな パーシステンス層アーキテクチャパターンについて自分の考えを述べよ パーシステンス層アーキテクチャパターンの選択 それでは、どのパーシステンス層のアーキテクチャパターンを選択すべきでしょうか? これは、ドメイン層のアーキテクチャパターンの選択に大きく依存します。PoEAAでは、以下の様な組み合が考えられるとしています。 ドメイン層アーキテクチャパターン パーシステンス層アーキテクチャパターン Transaction Scriptパターン Row Data Gatewayパターン Table Data Gatewayパターン Domain Modelパターン Active Recordパターン Data Mapperパターン Table Moduleパターン Table Data Gatewayパターン ドメイン層とパーシステンス層はどの様な組み合わせでもかまいませんが、 より合わせやすいパターンは上記の様な組み合わせといっています。 また、少し視点を変えて各アーキテクチャパターンとシステムの論理的な階層の依存関係を表すと以下のように成るかと思われます。 【図】パーシステンス層/ドメイン層アーキテクチャパターンの依存関係 かなり抽象的かつ感覚的な図ですので、大体の感触をつかんでいただければ良いのですが、 1つ言えることは、システムの論理的な階層である、ドメイン層とパーシステンス層は、 其々異なる役割を持った層ですので、お互いに依存が少ないほうが好ましいと思われます。 その点で言うとDomain ModelとData Mapperがお互いの層で依存関係が少なく済みます。 なんか最初から予備知識が 必要な話になってるけど それだとレスがつけにくいと思う >>3 >図書館やレンタルビデオの >貸出管理をどう設計するか くらいの話から始めればいいんじゃないの? レンタルビデオをドメインモデリングでやるとしたら ドメイン層にはまず 会員クラスがあってビデオクラスがある 貸出管理クラスで両者の情報を参照して貸出処理する そのほか料金クラスや期日クラスも要るだろう ここら辺はそんなに極端な差は出ないと思う >>42 >貸出管理クラスで両者の情報を参照して貸出処理する おっと思いつきで書いちゃったけど 貸出の操作をするのはアプリ層か ドメイン層では貸出の整合性を取るが やり方はいろいろあると思う >要件定義 ・ビデオ(DVD/CD)の貸出を処理できる → 料金や期日ももちろん提示する ・ビデオが貸出中や貸出可能かどうか検索できる ・貸出期限を過ぎた会員を検索できる 必要最低限の要件はざっくりこんな感じ もちろん実務だと会員が何百万人いて DBの性能要件とかあるだろうが お題であまり複雑にしても仕様がない あ、会員やビデオの登録や更新 (CRUD)はもちろん必要 穴だらけだけどそこら辺は みんなでつついてくれ ユースケース 客 CD/DVDを借りる CD/DVDを返す CD/DVDを借りパクする 店員 店員登録 店員削除 ログイン ログアウト 会員登録手続きをする 会員退会手続きをする CD/DVDを借りる手続きをする CD/DVDを返す手続きをする CD/DVDを期限切れても返さない客に催促する 店員 CD/DVDの状態取得 CD/DVDの新規登録 CD/DVDの削除 が無いと現在の状況がわからんのと 新しい商品の登録ができん もっとユーザー要求に近いところから整理したほうがいいのでは? システム構想ありきでユースケース書いてるように見えるが 期限や料金は貸出案件オブジェクトの属性にしたくなるな >>50 お題は叩き台だから 具体的に要求を出してくれれば 現実にありそうな要求としてはたとえば DVDの貸出回数を記録して 月間トップ10を出すとかね >>51 その場合たとえば 期日クラスに問い合わせると インスタンスを返してそれを 貸出側の属性に持たせるとか データとしては 店員 会員 CD/DVD状態 貸出記録 返却記録 ぐらい? >>3 このレスって10年ぐらい前に見た気がする デジャヴュなのかありきたりすぎる話題なのか本当に過去にもあったものなのか 狐につままれてるみたいだ 新機軸も何もなくただ建てられただけで>>3-4 みたいな 流れのままだとありきたりなクソスレに終わる 毎年春に新入社員が受ける教育のようなくだらなさ 実際ハロワとかの職業訓練ではjavaでレンタルビデオ店のシステムを作ろう みたいのを一年かけてやる で、書いたコードを手元に持ってて面接で見せるらしい >>55 レンタルビデオの例は リファクタリングの本に載ってるから モデリングの題材として定番なんだよ >>56 じゃあ新しい話題を振ればいいじゃん ないなら定番になるのは仕様がない 設計思想とはいうものの 実際は実装に引っ張られるので漠然と語ることなんてなかなかない 余程大規模じゃない限り会社の特性がありそれによって実装に制約が生じる その点を考慮しての要求設計がなければまともなものはできない お題をもとに設計について議論しようとしてるスレ? 設計思想はあんまり関係ない? もしそうなら 議論の対象を「CD/DVDの貸出」のユースケースに絞って もう少し深く要件考えるといいんじゃないかな 貸せるかどうかの判定ルールだったり レンタル価格の算定ルールだったり >>60 >設計思想はあんまり関係ない? 1じゃないけど 別に好きな話題振ればいんじゃね? >>40 でもこれに誰もレスしてないから いきなり深い設計思想を語っても 言うほどみんな乗ってこないじゃん 設計思想なのにデザパタって書いてあるスレタイが悪い >>54 顧客(特化: 会員/非会員) 店員 作品(属性: 保有数, 返却期限, 単価) (特化: CD/DVD) →導出: 現在貸出中の数 & 貸出可能数 単品(属性: 識別子, 状態: 未貸出/未返却) 取引 個人的には>>40 兄貴の講義にも興味があるけどな。 具体例を上げて解説して欲しいところではあるが。 >>61 そっか 「お題に沿って設計してみた」的なスレになれば有意義だと思うが 設計思想云々は設計思想って言葉を理解せずに使う人しかいないからゴミスレになる予感 機能一覧 店員登録 店員削除 ログイン ログアウト 会員登録 会員退会 CD/DVD貸出 CD/DVD返却 CD/DVD期限切れ CD/DVDの状態取得 CD/DVDの新規登録 CD/DVDの登録削除 こんなもんかな? あ、データの編集ができないな 店員編集 会員編集 CD/DVD編集 追加で 機能一覧 店員登録 店員編集 店員削除 ログイン ログアウト 会員登録 会員編集 会員退会 CD/DVD貸出 CD/DVD返却 CD/DVD期限切れ CD/DVDの状態取得 CD/DVDの新規登録 CD/DVDの編集 CD/DVDの登録削除 こんなもんかな? よく考えたらログインログアウトいらんね 削除ね 機能概要 店員登録 店員情報を店員Tblに登録する 店員編集 店員情報を編集する 店員削除 店員情報を削除(休眠)する 会員登録 会員情報を会員Tblに登録する 会員編集 会員情報を編集する 会員削除 会員情報を削除(休眠)する 機能概要 CD/DVD貸出 貸出情報を貸出tblに登録する CD/DVD返却 返却情報を返却tblに登録する CD/DVD期限切れ 期限切れの貸出情報を表示する CD/DVDの状態取得 CD/DVD情報を表示する CD/DVDの新規登録 CD/DVD情報をCD/DVDtblに登録する CD/DVDの編集 CD/DVD情報を編集する CD/DVDの登録削除 CD/DVD情報を削除(休眠)する できた 俺はここまでで組めちゃうかも オブジェクト指向設計とかいらね >>73 これ、それぞれ設定画面作って OKボタンの処理でDB操作するだけだわ これ作ってもらわなわからんって言うなら 掲示板で設計の話は無理なのかもしれん ちなみに俺もテキトーに考えたので抜けやらなんやらあってもわからん 機能概要 CD/DVD紛失 CD/DVD紛失情報をCD/DVD紛失tblに登録する もいるかも ・要求設計や上流工程の本読んでるといつもそうだが、 実際に自分とは関係ない具体例出されると集中力が保てなくてすぐに 眠くなってしまう。 ・いや、実際に自分が手がけている案件だって同じだ、議論領域に対して 正直な所興味が持てない。 ・つまりプログラミングやアーキテクチャには興味があるが、 ドメイン領域に対して学習意欲がわかないというかなんというか。 >>76 周りが見えてないから なんで後から追加・変更するの? とか起きないためには 受け取った要件定義書や設計書を 自分がその資料をデバッグできなければならない ここで漏れがあったらこれで作成できますと言った自分にもある程度の責任はついてくる 俺が出した機能概要で君はソフトウェアを作れるの? 作れないなら足りないところを言って 後からアレがないコレがない騒がないでよ これで見積りを出すから って状況なら嫌でも興味が湧くだろ? ・次のクライアントへのインタビューを読み、 設問に解答してください。 やったぜ。 者:変態糞土方 (8月16日(水)07時14分22秒) 昨日の8月15日にいつもの浮浪者のおっさん(60歳)と先日メールくれた汚れ好きの土方のにいちゃん (45歳)とわし(53歳)の3人で県北にある川の土手の下で盛りあったぜ。 今日は明日が休みなんでコンビニで酒とつまみを買ってから滅多に人が来ない所なんで、 そこでしこたま酒を飲んでからやりはじめたんや。 3人でちんぽ舐めあいながら地下足袋だけになり持って来たいちぢく浣腸を3本ずつ入れあった。 しばらくしたら、けつの穴がひくひくして来るし、糞が出口を求めて腹の中でぐるぐるしている。 浮浪者のおっさんにけつの穴をなめさせながら、兄ちゃんのけつの穴を舐めてたら、 先に兄ちゃんがわしの口に糞をドバーっと出して来た。 それと同時におっさんもわしも糞を出したんや。もう顔中、糞まみれや、 3人で出した糞を手で掬いながらお互いの体にぬりあったり、 糞まみれのちんぽを舐めあって小便で浣腸したりした。ああ〜〜たまらねえぜ。 しばらくやりまくってから又浣腸をしあうともう気が狂う程気持ちええんじゃ。 浮浪者のおっさんのけつの穴にわしのちんぽを突うずるっ込んでやると けつの穴が糞と小便でずるずるして気持ちが良い。 にいちゃんもおっさんの口にちんぽ突っ込んで腰をつかって居る。 糞まみれのおっさんのちんぽを掻きながら、思い切り射精したんや。 それからは、もうめちゃくちゃにおっさんと兄ちゃんの糞ちんぽを舐めあい、 糞を塗りあい、二回も男汁を出した。もう一度やりたいぜ。 やはり大勢で糞まみれになると最高やで。こんな、変態親父と糞あそびしないか。 ああ〜〜早く糞まみれになろうぜ。 岡山の県北であえる奴なら最高や。わしは163*90*53,おっさんは165*75*60、や 糞まみれでやりたいやつ、至急、メールくれや。 土方姿のまま浣腸して、糞だらけでやろうや。 ↑上記「とうこう」者 : 変態糞土方の部分の 「とうこう」がNGワードになっていたので削除しています。 <補足> ・クライアントの変態糞土方さんは、この経験を元に、 「糞遊びの会」のサイトを新たに立ち上げたいと考えました。 ・このサイトでは会員登録を行い、会員については年齢、身長、体重 それから住所、性癖、空いている時間帯などを管理したいと考えています。 ・このサイトでは会員/非会員などの間で掲示板でコミュニケーションを とるソーシャルメディアとして活用したいようです。 ・また、会員同士ではメッセージをやり取りし、オフ会を開くきっかけ を作りたいそうです。 <設問> ・1: この記述を元に、クラス図、業務フロー図、アクティビティ図、 ユースケース図/記述などを作成しなさい。 ・2: 実装段階において活用できそうなデザインパターンについて 解答しなさい。 ・3: このシステムの問題点はどのようなところにあるか考え、 実運用開始にあたって発生することが懸念されるインシデント 及びその対応策について述べなさい。 あぁ^~速く回答まみれになろうぜ。 回答したいやつ。至急レスくれや。 バージョンアップ時の設計について質問 今回バージョン1.0.0のアプリをバージョン1..0.1にしようとしています。 その時に1.0.0ではなかったソフトを1.0.1では導入しようと思っています ・1.0.0:アプリAのみ ・1.0.1:アプリA+別アプリB+テキストファイル ※ファイル通信を行っていたものがもともとアプリA バージョンアップでアプリAからファイル通信機能を無くし 別アプリBにファイル通信機能を持たすことになっています バージョンアップするときはアプリAの上書+アプリBの導入で良いのですが、 バージョンダウンする時アプリBとテキストファイルが1.0.0では不必要なので削除しないといけないです。 このようなとき、ファイルを削除するのであればバージョンを判断して削除したり削除しなかったりを 決める以外に判断材料はないでしょうか? バージョンで判断して削除するような設計しようとしていたのですがバージョン自体はアプリAに埋め込まれているため インストールをしたアプリのバージョン取得をできません また、次回起動時に削除してしまえばいいのかと思っていたのですが、バージョンが古いアプリAだと別アプリBの存在を知らないため削除できません インストール時に何かしら判断する方法をアドバイスほしいです テキストファイルにはアプリBの処理の分岐処理に使うようなキーを書く予定で これを上手く使えないかなと考えています >>82 デスクトップアプリの話? 1つのアプリの中のコンポーネントとして AとBとテキストファイルがあるという理解でいい? スイート製品でアプリBのみのアンインストールや アプリAのみのアンインストールやバージョンアップができるの? 内容からして前者だと思うけど その場合AやBはアプリとは呼ばない気がする >>82 一般的にバージョンダウン時は インストール済みバージョンのアンインストーラを使ってアンインストールしてから 旧バージョンをインストールしてもらう アンインストールせずに旧バージョンをインストールしようとしたら 新バージョンがインストールされてることを検知して アンインストールするかどうかをユーザーに確認する アンインストーラをキックして アンインストール後に旧バージョンのインストーラに制御を戻すことも可能 >>83 デスクトップアプリです 前提:PC1の持つデータをPC2にインストールする バージョン変更のボタン1つのみ(バージョンアップ・バージョンダウンの個別ボタン無し) ※PC1が持つデータがただ古いか新しいかの違いのみ 1つのアプリのコンポーネントとして〜というよりは システム全体でAの実行ファイルとBの実行ファイルとテキストがあるって感じです システムって言うと抽象化なのかな・・・? あるシステムには今までは実行ファイルAしかなく、今度のアップデートからからは 実行ファイルAと実行ファイルBとテキストファイルになる 単体でのアップデートなどはできず アップデートってすると前提にある様にPC1にあるデータを全てPC2に書き込む流れです >>85 おーん、、、何やら変わったアプリだね…. それはいいとしてアップデート=バージョンアップだよね? でアップデートする場合はPC1にあるデータをPC2に書き込むのはわかったけど バージョンダウンする場合はPC2の実行ファイルAを古いバージョンにして かつ不要な実行ファイルBとテキストファイルを削除したいってことでいい? だとすれば実行ファイルAを古いバージョンにする時に 実行ファイルBとテキストファイルを削除すればいいと思うんだけど? 質問を理解できてないのかもしれんが それが出来ない理由がいまいち分からん >>86 アップデート=バージョンアップで問題なしです やりたいことも、削除したいってことでOKです あー今気づきました ファイルAを古いバージョンにする時にこいつが古いバージョンだ!って判断するのが どうやってすれば良いんだろうと悩んでるところです。。。 >>87 インストーラとかアンインストーラとかはあるんだよね?? 1.0.1のAがインストール済みの環境で 1) 1.0.0のインストーラ/アンインストーラが起動された場合 対応バージョンより新しいのが入ってるのを検知して新バージョンのインストーラ/アンインストーラを使うように促す (バージョンダウン時は新バージョンのアンインストールをしてから再度旧バージョンのインストーラを使ってもらう) 2) 1.0.1のインストーラ/アンインストーラが起動された場合 Bやテキストファイルの存在を知ってるので削除可能だよね? バージョンダウンに直接対応したアンインストーラ兼インストーラを用意する場合も同じ 世の中一般のパッケージソフトはおおよそ上の仕組み使ってる 旧バージョンのインストーラが使えない状況で バージョンアップ時に旧バージョンのAを退避しておく必要があるとかそういうことなのかな? >>82 バージョニングが複雑になるときは 1. バージョンの記述を設定ファイルに外出しする 2. AとBと実行ファイルごとにバージョンを振る 3. バージョン変更するためのバッチや専用アプリを書く 上のどれかでだいたい行けるはず 番号が小さいほど導入の手間が少ない >>82 とりあえずセマンティックバージョニングでググってこい ______ ,;i|||||||||||||||||||||||||||||||ii;、 _/ /||||||||||||||||||||||||||||||||||||||ii;、 \ / ̄ ̄\||||||||||||||||||||||||||||||||||||ii;゙ヽ, / '" ̄ヽ ヽ!!|||||||||||||||| ||||||||||!!"ヘ < セマンティックageるよ ヽ ゙!!!|||||||||||| |||||||!! iヽ── / |||l ゙゙ヽ、ll,,‐''''"" | ヽ||||||||| セマンティックageるよ |||l ____ ゙l __ \||||||||| ||!' /ヽ、 o゙>┴<"o /\ |'" ̄| ホントの勇気 見せてくれたら \ / |ミミヽ──‐'"ノ≡- ゙'──''彡| |、 | |  ̄| |ミミミ/" ̄ 、,,/|l ̄"'''ヽ彡|| |、/ / セマンティックageるよ ヽ、l| |ミミミ| |、────フヽ |彡l| |/ /_ \/|l |ミミミ| \_/ ̄ ̄フ_/ |彡|l/  ̄/ セマンティックageるよ \ ノ l|ミミミ| \二二、_/ |彡| フ  ̄\ l|ミミミ|  ̄ ̄ ̄ |メ/ \ トキメク胸に キラキラ光った | \ ヽ\ミヽ  ̄ ̄"' |/ / / \ヽ、ヾ''''ヽ、_____// /_ バージョンをageるよ / ヽ ゙ヽ─、──────'/|  ̄/ . / ゙\ \ / / \__ ───'''" ̄ ̄ ゙゙̄ヽ、__,,/,-'''" ̄ ゙''─ >>90 リファクタリングしただけかもしれんぞ まあそうじゃなくてもその会社で決めたバージョニングスキームに従えばいいでしょ >>92 「会社で決めた決めたバージョニングスキーム」が読みとれたのかい? どっちにしても質問者はセマンティックバージョニング知らなそうだから、プラスになると思うよ アナリシスパターンとデザインパターンの関連性 って対応表みたいなのあるかな? >>94 どういう目的で関連や対応を知りたいの? アナリシスパターンはデータモデルのパターンだから デザインパターンとは基本的に関係ないよ フリーでUMLデザインツールといえば、なにがおすすめですか? 設計のご相談 あるソフトのバージョンアップをしたいと考えている んでもってそのバージョンアップに伴い既存ファイルに新しいキーが追加される その状況で考えて欲しいです そのファイルは現在インストーラーが上書きすることになっているため新バージョンがリリースされる度に上書きされます そのためキーの値を保持し続けることができません (キーは書き換える可能性があるものです) インストーラを変更させずにキーを保持し続ける方法無いでしょうか キー変更をするためのバッチファイルを準備しようとは思っていますがそれを使ってなんとかならないものだろうか 例 1.0が現在のキーなし 1.1が新しくキー追加 1.2がキー追加などなくバージョンアップのとき 1.1でキー追加→バッチファイルを実行しキー値を変更する→1.2のバージョン上げるとキーがデフォルトに戻る インストーラーを変更しない理由が見当たらないけど インストーラーの仕様漏れをなんとかリカバリできないかと苦労してるって話なのかな? >>99 そうです 普通に考えたらインストーラを上書きしないようにすることで解決すべきことなんでしょうが それが今回何故かNGでそれをどうにか回避できないかと 設計というか仕様の話だよね インストーラーが本来すべき仕事だったそのバッチプログラムで肩代わりするしかない バッチプログラムにキーの退避・復旧機能を入れてインストーラーの前後で実行してもらう サポート対応コストを考えるとインストーラー修正のほうが絶対に安上がり それにバッチプログラムで尻拭いするとしても インストーラー担当にケツを拭かせるようにしないとろくな事にならないよ やはりインストーラを修正しかないか... インストーラ修正はテストの範囲が膨大になるからしたくなかったが... キーの退避・復旧機能って言うとどうやってやるもんなんだろ やっぱりtmpファイルを作っておくものかね? イベントや状態遷移の設計についておすすめの書籍ある? クラス設計をした結果継承もまったくなく1つのクラスに収まったんだけどそれってクラスにする必要あるもんなんかね? >>105 必須ではないってのはわかってる 一つにまとまったものをクラスとして置いておく必要あるんかな?ってなってる ただの関数でもいいんじゃないかと >>106 メソッドひとつだけなら別に関数でもいいが ふたつ以上必要なら意味はあると思う >>107 メソッド三つ四つあるかな あるライブラリをc++で呼び出す(コマンド実行)ためのコーディングをするためにクラス設計 ライブラリは色々なプロトコル(HTTP,FTPなどなど)をサポートしてたからそれにあわせてクラス設計中 メンバ変数 ・char プロトコル ・char ユーザ名 ・char パスワード ・char 実行コマンド ※実行コマンドはexe -u ユーザ名 -pa パスワード -p プロトコル名 その他オプションみたいなsystemに渡す出来上がった形 ふるまい ・コンストラクタ(プロトコルやユーザ名やパスワードを引数とする) ・実行コマンド作成 ・実行コマンド実行 ・実行後の終了待機 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる