3、2　ソフトワェア設計 システム設計 ①外部設計 ②内部設計 ③プログラム設計   ▲外部設計(external design) システムの期待される機能からシステムを「サブシステム」に分割し、各サブシステムの設計を行う。 主にユーザーの立場からの設計である。 ①ユーザーの要件を満足するようなシステムのサブシステムへ分割が行われる。すなわち、ユーザーがシステムを容易に

▲黒板システム 分散する独立した知識を「黒板」と呼ばれる共用メモリに集めて相互作用を行うシステムであり、人工知能の分解で利用されている。 「黒板システム」では、知識源によって、「黒板」の更新を徐々に繰り返すことで問題を解決する。例：「信号処理」「パータン認識」。     ▲ソフトワェア．アーキテクチャのレベル ①概念レベル：抽象化されたシステムについてのソフトワェア

▲データ抽象化 データ表現とデータ付随する基本的操作をカプセル化するもの。データ抽象化アーキテクチャのコンポーネントはオブジェクトとなる。 「データ抽象化」では、「ソフトワェア構造」、「仕様」、「言語問題」、「統合」、「情報隠蔽」などの理解が包含している。よって、「データ抽象化」はオブジェクト指向アーキテクチャの基礎と考えられる。   ▲イベント指向システム 処理を行う手続きを

今天下班早一点，可以早点来了，呵呵。 继续。   三、ソフトワェア．アーキテクチャ 3、1ソフトワェア．アーキテクチャ(software architecture) 抽象度の高いトップレベルの設計はシステムを主要構成要素に分解し、それらの構成要素がいかに関連するかを規定するものである。 ソフトワェア．システムの大規模化と複雑化に伴い、設計の問題はアルゴリズムとデータの構造の問

▲デプロイメント図システム動作する時のコンフィグレーションを表現するための図。例:インターネット対応のデータベース．システムのデプロイメント図パソコン（ＰＣ）とデスクトップ．コンピュウータがアプリケーション．サーバを介入して、データベースを利用している、また、ＰＣの利用においては、ファイアウォールが設定されている。 ＵＭＬにおける図形式化によって、オブジェクトの設計も容易になる。問題点：①ＵＭＬの

▲アクティビティ図ステートチャート図の特別な形である、すなわち、アクティビティの流れが記述される。よって、フローチャートやデータフロー．ダイアグラムを表現することができ、条件分岐や並行処理の記述も可能である。  ▲コンポーネント図ソフトウェア．コンポーネント間の依存関係を示す図である。System.javaというソース．プログラムから、クラス．ファイルとhtmlファイルが生成されることを示すコンポ

前言：这个星期累坏了，今天上午还有事情出了趟门，结果中午的午睡就从下午两点一口气睡到了下午5点半，但还是困，睡眠不足啊，想着还是不要每天都来更新了，但是就怕这个口子一开，将来找借口就有理由了，算了，还是每天翻一点好了，贵在坚持，还好剩下的也不多了。好了，言归正传，继续昨天的翻译。 ▲シーケンス図オブジェクト間のインタラクションを時間的に表示する図である。例：前の銀行ＡＴＭにおける払い戻し ▲ステー

 ▲ユース．ケース図 システムの要求仕様を実現するための機能を表現する。 ①システムの提供する機能である「ユース．ケース」(usecase)、記号：楕円 ②システムのユーザーである「アクタ」(actor)。記号：③これらの「関係」(association)、楕円内に記述される。例：レストランのユース．ケース図 ▲コラボレーション図オブジェクト間のインタラクション(interaction)を空間的に

 ▲クラス図クラス間の静的な構造を表現する図である。一般化(generalization)：「汎化」もと言われ、「継承」に相当する関係。記号：関連(association)：関連性をもつ複数のオブジェクトの接続。記号：——依存(dependency)：関連に分類されない依存関係の接続。記号：－〉実現(realization)：インターフェイスのクラスによる実装。集約(aggregation)：記号

  ▲ＵＭＬ 厳密に言うと、分析、設計用の言語であり、開発に関する規定がないので、方法論とは言えない。したがって、適当なオブジェクト指向開発法と組み合わせて利用する必要がある。 「記法」(notation) UMLがオブジェクト指向型プログラミング言語「java」との親和性も高い。 次の九個の図が用いられる。 ①クラス図(class diagram) ②オブジェクト図(ob

▲クラス間の関係①継承(inheritance)：is-a関係(is-arelation)②集約(aggregation)：has-a関係(has-arelation)前図において、「円」のクラスは「図形」のクラスの性質を継承する。「図形」は面積を持つが、「面積」という性質は「円」のクラスに継承される。すなわち、内部状態の変数と各種のメソッドが継承される。「集約」は「部分関係」によって記述される。

 4、オブジェクト指向分析(object-orientedanalysis:OOA)オブジェクト方法論がオブジェクト指向分析の以外、下記の内容も含む。オブジェクト指向設計(object-orienteddesign:OOD)オブジェクト指向プログラミング(object-orientedprogramming) ▲オブジェクト指向の基本概念オブジェクト：実世界の対象に対応するコンピューターで表現すべ

▲データ辞書の記述データフロー．ダイアグラムで利用される用語の定義をある規則で並べたものである。①データフロー②ファイル③プロセス④データ要素：データのそれ以上小さく分解できない要素である。ＢＮＦ(Backus-Naurfrom：バッカスニナウアー記法)①Ａ＝Ｂ：ＡはＢに等しい。②Ａ＋Ｂ：Ａ且つＢ。③［Ａ｜Ｂ］：Ａ又はＢ。④｛｝：括弧内の要素の反復。⑤（）：括弧内の要素の任意選択。例：看護婦業務：

3、構造化分析(structuredanalysis)システム要求を分割し、それらのインターフェイスの分析して、システム要求全体を「構造化仕様書」(structuredspecification)と呼ばれる仕様書としてまとめる、トップダウンの分析法である。構造化とは、システム全体をトップダウンで構成要素に分解し詳細化する考え方であり、最終的にはこれらの構成要素の集まりとしてシステムは記述される。「

 2、実体関連モデルERモデルデータ指向分析のための重要な技法の一つである。だーたモデル：データを解釈するためのモデル。実体（entity）、属性(attribute)、値(value)、関連(relationship) ▲実体関連図（ERdiagram）1対1関連：一つの実体に対して一つの実体が対応する関連である。1対多関連：一つの実体に対して複数の実体が対応する関連である。多対対関連：複数の実

二、要求工学 1、要求定義 ユーザーのソフトワェアに対するニーズであり、これらを分析して明確化するのが「要求定義」の目的である。   ▲システムの分析方法 ①データ指向分析：システムをデータの観点から分析する、データベース(database)の世界 ②プロセス分析：各種処理をプロセスと見なしてシステムを分析する。ウォートフォール．モデルと構造化分析を含む。 ③オブジェクト指

▲プロトタイピング．モデル(prototypingmodel)使い捨てプロトタイプ(throwawayprototyping)発展的プロトタイプ(evolutionaryprototyping) 利点：①開発者とユーザのシステムに対する認識を短時間に収束させる。②システムのイメージを明確にする。③短時間のシステム開発可能。欠点：①ユーザの意見の調整がうまくいくまで開発が進まない。②設計時の誤りなど

 2、プロセス．モデルソフトワェア開発モデル①プロセス．モデル：効率的に開発するかの観点ウォータフォール．モデル、成長モデル、プロトタイプ．タイプ、スパイラル．モデル②コスト．モデル：作業量などのコストハルステッド法、ファンクション．ポイント法、COCOMO ▲ウォータフォール．モデル(waterfallmodel)利点：①モデル単純②工程管理容易③開発履歴はっきり、下流工程におけるテストと保守が

▲実装（implementation） 　つまり、コーディング/プログラミング 　設計結果を具体的なプログラミング言語で記述する作業である。 　プログラミング言語が作るソフトワェアの性質やユーザの要望などに依存する。 　言語：手続き型言語（procedural programming） 　　　　オブジェクト指向言語　非手続き型言語 ▲テスト 　ソフトワェア．システムの構成要素であるプ

一、ソフトワェア開発モデル １、ソフトワェアのライフ．サイクル ▲工程（phase）：終了時に成果物として仕様書を作る。 ▲ライフ．サイクル 　要求定義 　設計 　実装 　テスト 　運用．保守 上流工程：要求定義、設計 下流工程：実装、テスト、運用．保守   翻译： 一、软件开发模型 1、软件的生命周期 △阶段：每个阶段结束的时候，制作式样书作为成果物。