Application Development Oveview
2 likes729 views
![オブジェクト • 「静的な構造」と「動的な振る舞い」に着
目して分析及び設計をする方法論
– オブジェクトを組み合わせて構築
– オブジェクトはデータ構造や処理内容を外部
から隠蔽（カプセル化）した単位
– オブジェクト間でメッセージを送受信して動作
– UMLにより構造を記述
• ユースケース図
• クラス図
• シーケンス図
24
オブジェクト指向アプローチ（OOA）
プロセス(振る舞い) と データ(属性)をまとめたオブジェクトを対象にした開発アプローチ
プログラム
[メソッド]
(振る舞い)
プログラム
[メソッド]
(振る舞い)
プログラム
[メソッド]
(振る舞い)
データ
(属性)
クラス
インターフェース
インターフェース
インターフェース
オブジェクト](https://image.slidesharecdn.com/applicationdev-170928130249/85/Application-Development-Oveview-24-320.jpg)
Application Development Oveview
- 5. • 具体的な目的のための作業に 用いられるソフトウェア – アプリケーション・ソフトウェア • オペレーティングシステムの拡張や アプリケーションの汎用機能などを 提供するソフトウェア – ミドルウェア / ランタイム • 「オペレーティングシステム」や 「ドライバ」などコンピュータ制御の ためのソフトウェア – 基本ソフトウェア/システムソフトウェア 5 “アプリケーション”とは 特定の目的のために設計・開発されたソフトウェア ドライバ オペレーティングシステム ハードウェア ランタイム/ ミドルウェア アプリケーション
- 6. 6 デバイス専用のアプリケーション / マルチ・プラットフォーム “アプリケーション”の実行環境 様々なデバイス用のアプリケーション モバイル アプリケーション デスクトップ アプリケーション Web アプリケーション ホスト アプリケーション ・・・など オペレーティングシステム （ カーネル） ランタイム/ ミドルウェア アプリケーション システムコール • アプリケーションの動き方 – デバイスに関係なく共通 • アプリケーションを実装している プログラム言語（ランタイム）から、 OS カーネルのシステムコールを 行う • デバイス（プラットフォーム）毎の アプリケーション – それぞれで異なる命令セット • それぞれに専用アプリケーション を作成 • 異なる命令セットを吸収する ランタイム プログラム 言語
- 7. • 高級言語 / 低級言語 – 高級言語：自然言語に近い形式 • 最終的には機械語に翻訳 – 低級言語：H/Wが理解可能な形式 • コンパイラ方式 / インタプリタ方式 – コンパイラ（事前翻訳）： • 予めプログラムを翻訳し実行ファイルを生成 • プログラムの変更毎に再翻訳が必要 – インタプリタ（逐次翻訳）： • 実行毎に１命令ずつ翻訳しながら実行 • 実行時コンパイラ(JIT) 7 プログラム言語 アプリケーション（コンピュータプログラム）を記述するための形式言語 プログラム言語 低級言語 高級言語 • アセンブラ • 機械語 コンパイラ方式 インタプリタ方式 • C言語 • COBOL • Java • C# • Bash • JavaScript • Ruby • Python インタプリタ 併用
- 9. • アーキテクチャ – システムの基本構造 – 同じアプリケーションでも構造次第で 性質が変わる • 性能 / 信頼性 / 生産性 / ユーザビリティ 等 – システムの特性(要件)に合わせた 適切な設計が必要 • アーキテクチャ設計 – システムに要求する「What」と「How」 を明確にする – What • 静的な構造 – ユーザ要求 – 品質要求 • 機能性 / 信頼性 / 効率性 / 保守性 等 – How • 動的なプロセス – 作業の順序関係 – 開発手法 9 “アプリケーション・アーキテクチャ”とは システムの特性合わせた構成 システム 観点 ビジネス 観点 ユーザ 観点
- 11. • メインフレーム / ダム・ターミナル – 計算処理及び記録機能は 全て巨大なサーバ（メインフレーム）で 実施 – クライアントは簡素なビューワーであり 「文字入力」と「結果表示」を実施 • アプリケーション – 主にCOBOL言語による開発 • 固定小数点数による１０進演算が特長 – 金融業務の記述の多く利用 11 メインフレームの時代 （～1980年代） 大型コンピュータによる集中処理 データ ロジック
- 12. • パーソナルコンピュータの登場 – PCの処理能力を活用し、 クライアント側とサーバ側での分業 • サーバ側 – 主要な業務処理 – 共有するデータの補完 • クライアント側 – データの加工・編集 – 画面（ユーザインターフェース）の描画 – Fat Client 12 クライアント/サーバの時代 （1980年代～1990年代） サーバサイドでデータを集中管理 / 各クライアントでロジック処理を実施 データ ロジック ロジック
- 13. • Windows の登場 – ブラウザをクライアント機能として利用 • クライアントサイドの開発・運用コストの削減 • ブラウザ技術の進化 – プラグインプログラム利用による RIA（Rich Internet Application） • Java Applet • Adobe Flash • Microsoft Silverlight • Curl 13 Web分散システムの時代 （ 1990年代後半～2000年台） ブラウザをクライアントとするWebアプリケーション データ ロジック ロジック
- 14. • クラウドの登場 – インターネット技術の進歩 – ネットワーク速度の向上 – クライアント端末の多様化 • マルチデバイス前提のクライアント – 機種依存するRIAの衰退 – HTML5 によるWebアプリケーション • スケールするサーバサイド • ファンクショナルな基盤 14 クラウドの時代 （2010年代） オンデマンドで利用可能なコンピュータリソースと多様化するクライアント端末 データ ロジック ロジック
- 15. 15 密から疎へ、プロプライエタリからオープンへ 分散システムの変遷 20201970 1980 1990 2000 2010 RPC CORBA RMI DCOM COM+ SOAP REST gRPC GraphQLMQ IPC COM Peer to Peer EAI SOA マイクロ サービス 分散処理技術 分散アーキテクチャ
- 17. 17 一般的なシステム開発 システム開発全体像 アプリケーション開発 インフラストラクチャ構築 • 基本設計 • 詳細設計 • 実装 • 単体テスト • 結合テスト • システムテスト • ユーザ受け入れテスト • 方式 • 非機能(性能/信頼性) • OS • ネットワーク • ミドルウェア 運用 • リリース • 移行 • 定常時運用 • 起動/停止 • 監視 • 障害時運用 • 代替運用 • 障害対応 • 復旧 保守 • 定期/緊急保守 • ハードウェア保守 • ソフトウェア保守 • ネットワーク保守 要件 • 経営戦略立案 • システム化計画 • 業務調査/分析 • 対象領域分析 • 個別システム化計画 プロジェクト管理 • スケジュール管理 • 要員管理 • 課題管理 • 品質管理 • ドキュメント管理 • プログラム管理 上流 下流
- 18. 18 一般的なシステム開発 システム開発全体像 アプリケーション開発 インフラストラクチャ構築 • 基本設計 • 詳細設計 • 実装 • 単体テスト • 結合テスト • システムテスト • ユーザ受け入れテスト • 方式 • 非機能(性能/信頼性) • OS • ネットワーク • ミドルウェア 運用 • リリース • 移行 • 定常時運用 • 起動/停止 • 監視 • 障害時運用 • 代替運用 • 障害対応 • 復旧 保守 • 定期/緊急保守 • ハードウェア保守 • ソフトウェア保守 • ネットワーク保守 要件 • 経営戦略立案 • システム化計画 • 業務調査/分析 • 対象領域分析 • 個別システム化計画 プロジェクト管理 • スケジュール管理 • 要員管理 • 課題管理 • 品質管理 • ドキュメント管理 • プログラム管理 ITIL 開発方法論 開発技法 ※SWEBOK
- 20. • アプリケーション開発の基本フロー – 分析：開発対象はどのようなものか – 設計：どのような構造にするか – 実装：どうやって効率的かつ品質の高く作るか • 開発方法論とは開発に要する 「方法」「手順」「手段」を体系化したもの – 方法、プロセス、発想、視点、技術、ツール • 分析方法/アーキテクチャ： – POA / DOA / OOA • プロセス観点： – ウォーターフォール / 反復型 / アジャイル 20 開発方法論（開発メソドロジー） アプリケーション開発に関する各種の「方法」「手順」「手段」を体系化して定義したもの 開発方法論 開発工程 要件 設計 実装 テスト プロセス 分析方法 ツール 発想/視点 技術 分析 設計 実装
- 21. • システム化する対象の業務領域の 「捉え方」や「重要箇所」による分類 – 処理や機能を重要視 – データやその構造を重要視 – 業務に伴うデータと処理の抽象化を重要視 21 開発方法論: 分析方法/アーキテクチャ観点 システム化対象領域に対する視点や着目点による分類 システム化対象業務領域 業務処理に 注目 業務データに 注目 業務の 抽象化 プロセス指向アプローチ データ指向アプローチ オブジェクト指向アプローチ
- 22. Bシステム Aシステム • 「システムが実現する機能」観点で 分析及び設計を実施する方法論 – 業務プロセスのプログラムを実装 – データは各プログラムに依存 – データの「入力」「加工」「出力」を記述 • HIPO – 図式目次 / IPOダイアグラム • DFD（データフローダイアグラム） • 欠点 – サイロ化したシステムになる – 冗長なプログラムが発生する – データの不整合や重複が起こりやすい 22 プロセス指向アプローチ（POA） 業務の処理内容に着目した開発アプローチ データプログラム データプログラム データプログラム データプログラム データは 各プログラムに依存
- 23. • 「システムを構成する安定要素」としての データを基に分析及び設計する方法論 – 以下の観点でデータの整合性を重視 • 「最も重要なリソースはデータである」 • 「組織的に管理・活用する資産である」 – 「エンティティ」と「リレーション」で分析 • ER図 • プログラムとデータ構造の分離 – 重複や不整合のないデータモデリング – プログラムのみの変更保守で済む事が多い • 欠点 – データ構造を変更した場合の影響特定が困難 23 データ指向アプローチ（DOA） システムを構成するデータの構造に着目した開発アプローチ Aシステム プログラム プログラム Bシステム プログラム プログラム データ
- 24. オブジェクト • 「静的な構造」と「動的な振る舞い」に着 目して分析及び設計をする方法論 – オブジェクトを組み合わせて構築 – オブジェクトはデータ構造や処理内容を外部 から隠蔽（カプセル化）した単位 – オブジェクト間でメッセージを送受信して動作 – UMLにより構造を記述 • ユースケース図 • クラス図 • シーケンス図 24 オブジェクト指向アプローチ（OOA） プロセス(振る舞い) と データ(属性)をまとめたオブジェクトを対象にした開発アプローチ プログラム [メソッド] (振る舞い) プログラム [メソッド] (振る舞い) プログラム [メソッド] (振る舞い) データ (属性) クラス インターフェース インターフェース インターフェース オブジェクト
- 25. • 各開発工程（ライフサイクル）の 手順化（プロセス化）の観点 – 開発工程は次のような選択肢がある • BOK記載の規格（PMBOK、SWEBOK） • ISO12207 • 商用プロセス – 一般的には以下の工程となる • 要求 • 設計 • 製造 • 検証 • 運用 – テーラリングし各プロジェクトに適用 25 開発方法論: プロセス観点 開発プロジェクトの種類や状況に応じた開発工程のモデル
- 26. • 上流工程から下流工程へ各工程の完了 を以て順次進める方法 – 各工程毎に計画や成果物を定義 – 前工程の成果物を各工程のインプット • メリット – 計画や管理を行いやすい • 各工程の開始/終了規定が明確なため、期間や 要員計画をたてやすい • 成果物に対する進捗管理が行いやすい • デメリット – 要求が不明瞭の場合の手戻りリスクがある – 仕様変更による影響が大きい 26 ウォーターフォール・モデル 各工程の成果物の品質を担保する開発モデル 要求定義 設計 製造 検証 運用 QA レビュー
- 27. • 開発初期に試作品の作成・評価・改善を 繰り返して要求確認を行う – 要求仕様の確認や評価 – ユーザインターフェースの確定 – 性能の確認 • メリット – 開発部門/利用部門との認識・解釈のずれや 曖昧さを取り除ける – 開発者は技術的なポイントを予め確認可能 • デメリット – 全体工数及び費用が肥大化する事がある 27 プロトタイプ・モデル 試作品を初期工程で作成し認識齟齬を確認する開発モデル 要求定義 設計 製造 検証 運用 プロトタイプ 作成 プロトタイプ 修正 プロトタイプ 評価
- 28. • ウォーターフォール/プロトタイプ型の長 所の組み合わせ – 独立性の高い部分に分解し、ぞれぞれの部品 で開発工程を繰り返す方法 – 開発リスクの最小化を目的とし、リスクの評価 と改善しなが進める • メリット – 仕様変更に対応し易く、手戻りが発生しにくい – 要件認識齟齬や設計ミスを早期発見できる • デメリット – 全体計画をたてにくい • 開発単位の分割・見積もりが困難 • ユーザに仕様変更の余地を与えてしまう 28 スパイラルモデル ウォータフォールモデルとプロトタイピングモデルの2つの長所を生かしたモデル 要求定義 設計 製造 検証 リリース
- 29. • 要求を複数に分割し順次開発・リリース を繰り返して機能追加していく方法 – システムの要素を段階的に開発・追加 – 全ての機能が揃わなくても動作確認可能 – システム化範囲/リスク軽減手段/期間やコスト /アーキテクチャ候補の検討と見直しを実施 • メリット – 早期に必要なものからリリースできる – 要求の確定しているものから着手可能 • デメリット – 全体計画をたてにくい 29 反復モデル 短期間の開発プロセスを複数回実施して小さな機能単位で追加する開発モデル 要求定義 設計 製造 検証 要求定義 設計 製造 検証 要求定義 設計 製造 検証 リリース リリース 反復 方向付 推敲
- 31. • 反復型開発 – 計画や管理を重視 – 当初要件や計画を遵守できるように、 品質、期間やリスクを反復毎に見直す • アジャイル開発 – 開発成果物によるビジネス価値の向上を重視 – 開発体制（チーム）に顧客が定常的に参加し、 ビジネス状況の変化を汲み入れながら 成果物の完成を目指す – 状況次第で初期計画時の成果物や期間など 変更が生じる 31 反復型開発とアジャイル開発の違い 計画重視：反復型開発 顧客重視：アジャイル開発 初期計画 期間 費用 成果物 反復 反復 反復 納品 初期計画 反復 反復 反復 納品 顧客 判断 ビジネス状況 の変化 反復型開発 アジャイル開発
- 32. アジャイルソフトウェア開発宣言：１２の原則 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継 続的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を 引き上げます。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだ け短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々 一緒に働かなければなりません。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼し ます。 6. 情報を伝えるもっとも効率的で効果的な方法はフェイ ス・トゥ・フェイスで話をすることです。 7. 動くソフトウェアこそが進捗の最も重要な尺度です。 8. アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければ なりません。 9. 技術的卓越性と優れた設計に対する不断の注意が機 敏さを高めます。 10. シンプルさ（ムダなく作れる量を最大限にすること）が 本質です。 11. 最良のアーキテクチャ・要求・設計は、自己組織的な チームから生み出されます。 12. チームがもっと効率を高めることができるかを定期的 に振り返り、それに基づいて自分たちのやり方を最適 に調整します。 32 ４つの価値の背景にある様々な行動規範
- 33. アジャイル開発手法 手法名 内容 XP 10個程度の具体的なプラクティスを定義し、ドキュメントの整備よりも ソースコードと開発者の責任を重視 スクラム アジャイルなプロジェクトを管理するためのフレームワーク リーン・ソフトウェア開発 無駄を排除しプロジェクトのコストとROIの属性を焦点 機能駆動型開発（FDD） ビジネス・ドメイン・モデルの定義とその単位での開発 アダプティブシステム開発 （ASP） 継続的な適応を前提とし、Speculate/Collaborate/Learnのフェーズから成る アジャイルユニファイドプロセス（AUP） リスク管理を徹底し、開発/推敲/構築/移行の各フェーズを反復する クリスタル プロジェクトの規模と重大度によるアプローチの変更 動的システム開発手法（DSDM） ビジネスユーザ視点による開発手法で予算と期日を重視する カンバン タスクを可視化し、チームメンバーに適量のタスクを与えて、チームが常に フル稼働で作業できるようにする 33 アジャイルな原則に基づく様々な開発手法
- 34. • 開発プロジェクト＝不確実性のある作業 – 開発手法は不確実性に対する戦略 – 開発プロジェクトの不確実性（リスク） • 要求リスク（要件誤認 / 仕様変更 / スコープ増大） • 技術リスク（製品不具合 / 性能,拡張性など非機能） • 要員リスク（適用技術経験がない、足らない） • 開発プロジェクトの制約に対する対処 – 制約：「要求(スコープ)」「リソース(人)」「納期」 34 従来型開発とアジャイル開発の考え方の違い VUCA時代の開発 確実な未来 選択的な未来 一定幅の未来 不確実な未来 計画可能な事は 計画して実施 計画不可な事は 確認しながら 変化に対応して 実施 予測 （計画駆動） 反復・適応 （変化駆動） ウォーター フォール アジャイル 要求 リソース 納期 リソース 納期 要求 計画 駆動 変化 駆動 固定された 見積もられた
- 35. • アジャイル開発は「する」のではない – 手法の適用が目的ではない • イテレーション開発する事がアジャイルではない – ツールの利用が目的ではない • テスト自動化ツールを使う事がアジャイルではない • ビジネスをアジャイル（俊敏・鋭敏）な 状態にする事が目的 35 アジャイル開発に対する誤解 Don’t just do agile. Be agile. 目的と目標・手段を取り違えている
- 36. • DevOps 対する誤解 – アジャイル開発をする事ではない – CI/CDを行う事ではない – Infrastructure as Code を行う事ではない – 定義されている開発手法ではない • DevOps のコンセプト – チーム間の隔たりをなくし、 迅速かつ継続的にアプリケーションを 開発・改善していく事 36 DevOps と アジャイル開発 DevOps ≠ アジャイル開発 要求定義 設計 製造 検証 開発 (Dev) 運用 (Ops) ビジネス部門 (Biz)
- 37. • アジャイル開発が導入されているケース – 製品開発 / 内製チームによる開発 • アジャイル開発の導入が困難なケース – スコープとスケジュールが必要な契約 – 成果物の納品が必要 – 全社開発方針が定められ変更が困難 – 準委任契約を短期・複数回行う余裕がない • 請負契約と準委任契約 37 アジャイル開発と契約 日本で受け入れられにくいアジャイル開発 人 物 金 • 階層的な組織構造 • 明確にルール付けされた行動 • 対立の回避 • チャレンジや失敗の回避 • 巨大なモノリシックな組織と モノリシックなアプリケーション • 内製より委託 • 仕様と納期を重視した契約（請負契約） • 契約に要する時間と工数 一括請負契約 準委任契約 完成責任 あり なし 瑕疵責任 あり なし 報酬 検収後に一括 一定期間毎
- 38. • 開発のアウトソーシングが課題 – 開発委託先との契約の仕方 • 請負契約から基本／個別契約や組合モデル • ユーザ企業内での契約ルールの変更 • 納品成果物等のルール変更 – 開発ベンダ内での開発手法の確立 • プロセス/メソドロジー/ツール • 社内プロジェクト承認プロセス – クオリティティ/リスク アシュアランス – コンティンジェンシープラン – 欧米型開発モデルの推進 • 内製化 38 アジャイル開発の展開 アプリケーション開発に対する取り組みの変化が重要 IT戦略 プロジェクト 戦術 アジャイルな ビジネス価値創造 アジャイルな開発 アジャイルな運用
- 40. • 開発工程 – アプリケーション開発で実施する 処理と手順を体系化/形式化したもの • 各処理の作業内容の定義 • 各処理で出力する仕様やドキュメントなどの 成果物の定義 40 “アプリケーション開発工程”とは 要求定義から運用保守までの一連の工程 要求/要件 定義 設計 製造 検証 運用 要求分析/定義 システム要件定義 方式設計 基本設計 詳細設計 実装 単体テスト 統合テスト システムテスト 受け入れテスト 移行 運用
- 41. • 顧客要求とシステム要件を明確化 • 要求分析/要求定義 – ビジネス施策 • 企業価値を高めるために必要な取り組み • 要件分析/要件定義 – システム化要件 • ビジネス施策の達成手段としてのシステム化 41 要求定義 顧客の要求とシステム化の要件を業務/機能の観点で明確化 要求 ビジネス価値を高めるための施策 要件 システム化するため要する範囲や機能 システム 人
- 42. • 基本設計 – 顧客のニーズ通りにシステム化される事を 基本設計内容を基に承認・合意を得る • 顧客のビジネス戦略や状況の理解が必要 – 動的な仕様と静的な仕様を記述 • 動的： 業務の流れや手順 • 静的： データの入出力や画面/帳票のレイアウト – アーキテクチャパターン • 詳細設計 – 外部設計の仕様を満たす事を検証・確認 • プログラム実装ミスを未然に防止 • モジュールの再利用を検討 – デザインパターン/アルゴリズム 42 設計 要件を実現するためのデータや処理方式の定義 基本設計 システム化要件の具体化（for 顧客） 詳細設計 実現方法の具体化（for 開発者） 業務 フロー図 UI 設計書 機能 設計書 非機能 設計書 データ 設計書 N/W 設計書 機能 設計書 イベント 設計書 開発 方針書 コード 規約 データ 設計書 UT計画
- 43. • ソースコード開発 – 詳細設計の仕様に基づくモジュール開発 – 開発規約に基づくコーディングスタイル • 単体テスト – ホワイトボックステスト • プログラムの制御構造を意識したテスト – 単体テストツールの利用 • 容易に自動かつ繰り返しテスト実施が可能 • テストコードの開発を要する – コーディング規約ツールの利用 • コーディングスタイルの自動判定 • 潜在バグを埋め込むコードの発見 43 製造 設計に従いプログラム言語による実装及び単体テストの実施 ソースコード開発 設計仕様/開発規約に基づいたソースコード開発 単体テスト プログラムの制御構造やロジックの正常性検証 ソース コード スタブ 命令 網羅 ソース レビュー テスト データ ドライバ バグ 対応 分岐 網羅 条件 網羅 テスト 項目 テスト コード テスト レビュー
- 44. • 統合テスト – ブラックボックステスト • 制御構造を意識せず、モジュール間/コンポーネント間/ サブシステム間の I/F 入出力の正常性をテスト – 継続的インテグレーション/デプロイの利用 • システムテスト – 性能テスト – ストレステスト – ロングランテスト – 障害テスト – 受け入れテスト 44 検証 要件及び設計を満たす動作である検証 統合テスト インターフェースを経由した連携の正常性検証 システムテスト 実際のシステム稼働を想定した検証 モジュールサブシステム コンポーネント モジュールコンポーネントサブシステム モジュールコンポーネント 性能 信頼性 可用性 ユーザー 利用 運用
- 45. • 運用 – システムを安全かつ正常に稼働させ続けるた めの作業工程 – 継続的に改善活動を実施 – ITILの利用 45 運用 アプリケーションの一般公開と安全に稼働するための監視及び保守 運用 管理 監視 保守 更新 移行 評価 障害 対応 対策
- 47. 47 様々なプログラム言語の系統 プログラム言語の系図 20201960 1970 1980 1990 2000 2010 Fortran COBOL LISP PL/I Smalltalk C C++ Java C# Java5 Java8Algol Scheme Rust ML Caml OCaml Haskel Pascal Python RubyPerl Go Swift Scala Groovy
- 48. • プログラム言語の型 データや関数の種類を分類するためのもの – 動的型付け • 実行時に型が決定 – 静的型付け • コンパイル時に型が決定 – 強い型付け • ある処理・演算が間違った型の引数をとることを禁止 • 1+1=2, 1.0+1.0=2.0 のように1と1.0は別の値として扱う – 弱い型付け • 言語が型の暗黙的な変換（またはキャスト） • ‘A’+1=‘A1’ のように暗黙的な値のあ使い方の変更 48 動的型付けと静的型付け プログラム言語の性質を位置づける型システム 動的 静的 強い型 弱い型 Java Scala Haskel C# C C++ Ruby Groovy Python Clojure PHP JavaScript Perl VB
- 49. • プログラミング・パラダイム – 命令型 • プロセッサに対する命令を記述 – 宣言型 • 対象の性質を宣言 – 手続き型 • 命令型と同義 • 構造化プログラミング • 手続きをいくつかの単位に分け、サブルーチンによって 細部を記述していく方法 – 関数型 • 複数の式を関数の適用によって組み合わせていく方法 – 関数が第一級オブジェクト （基本的な操作を制限なしに使用できる対象） – 論理型（述語論理式） 49 プログラミング・パラダイム プログラミングの方針に関する考え方による分類 宣言型言語 命令型言語 手続き型 言語 論理型 言語 関数型 言語 オブジェクト指向型言語 Java C++ Scala JavaScript Haskel C Prolog
- 50. 手続き型 オブジェクト指向プログラミング構造化プログラミング 50 開発方式の変遷 アプリケーション開発の歴史 20201970 1980 1990 2000 2010 メインフレーム クライアントサーバ インターネット クラウド 関数型プログラミング COBOL C Go オブジェクト指向C++ Java C# 関数型ScalaLISP Haskel プロセス指向アプローチ データ指向アプローチ オブジェクト指向アプローチ
- 51. Java Java SE / Java EE 51
- 52. • Java – 狭義：プログラム言語 Java – 広義：言語仕様を含む Java 自体の実行環境 • Java に関するターミノロジー – Java SE (Java Platform, Standard Edition) – Java EE (Java Platform, Enterprise Edition) – JVM (Java Virtual Machine) • ネイティブ環境と Java 命令セットの差異を吸収 – JRE (Java Runtime Environment) • API/JVMを内包するJava実行のために必要な最小セット – JDK (Java Development Kit) • JREを内包するJavaのコンパイラで開発時に必要 52 Java Java SE と Java EE Java EE Java SE 標準的な機能を 提供するAPIの集合 標準的なサーバサイド アプリケーションのための APIの集合 Java EE は、Java SE のAPI により実装されている JVM (Java 仮想マシン) JDK (Java Development Kit) JRE (Java Runtime Environment)
- 53. 53 エンタープライズ・システムを開発するための標準フレームワーク Java EE データベース MOM ディレクトリサービス メールサーバ レガシーシステム プレゼンテーション層 ビジネスロジック層 データアクセス層 Servlet JSP JSF JAX-RS JAX-WS EJB CDI JBatch JTA JDBC JMS JNDI JavaMail JCA Java EE
- 54. 54 エンタープライズ・システムを開発するための標準フレームワーク Java EE データベース MOM ディレクトリサービス メールサーバ レガシーシステム プレゼンテーション層 ビジネスロジック層 データアクセス層 Servlet JSP JSF JAX-RS JAX-WS EJB CDI JBatch JTA JDBC JMS JNDI JavaMail JCA Java EE クライアントからの リクエストを受けて スレッドで処理 Servletの画面描画 をHTML的に記述 UIコンポーネント ベースの フレームワーク RESTによる サービス公開 SOAPによる サービス公開 トランザクションや セキュリテイ制御 等の機能を提供 オブジェクトの 生成や取得の タイミングを制御 バッチ処理用 フレームワーク トランザクションの 管理
- 55. Java EE 7 • Web Application Technologies – Java API for WebSocket – Java API for JSON Processing – Java Servlet 3.1 – JavaServer Faces 2.2 – Expression Language 3.0 – JavaServer Pages 2.3 – Standard Tag Library for JavaServer Pages 1.2 • Enterprise Application Technologies – Batch Applications for the Java Platform – Concurrency Utilities for Java EE 1.0 – Contexts and Dependency Injection for Java 1.1 – Dependency Injection for Java 1.0 – Bean Validation 1.1 – Enterprise JavaBeans 3.2 – Interceptors 1.2 – Java EE Connector Architecture 1.7 – Java Persistence 2.1 – Common Annotations for the Java Platform 1.2 – Java Message Service API 2.0 – Java Transaction API 1.2 – JavaMail 1.5 • Web Services Technologies – Java API for RESTful Web Services 2.0 – Implementing Enterprise Web Services 1.3 – Java API for XML-Based Web Services 2.2 – Web Services Metadata for the Java Platform – Java API for XML-Based RPC 1.1 – Java APIs for XML Messaging 1.3 – Java API for XML Registries 1.0 • Management and Security Technologies – Java Authentication Service Provider Interface for Containers 1.1 – Java Authorization Contract for Containers 1.5 – Java EE Application Deployment 1.2 – J2EE Management 1.1 – Debugging Support for Other Languages 1.0 • Java EE-related Specs in Java SE – Java Architecture for XML Binding 2.2 – Java API for XML Processing 1.3 – Java Database Connectivity 4.0 – Java Management Extensions 2.0 – JavaBeans Activation Framework 1.1 – Streaming API for XML 1.0 55 Java EE 7 仕様一覧
- 56. J2EE 1.3 CMP JCA 堅牢性 スケーラブル J2EE 1.4 JAX-RPC Deployment Webサービス Java EE 5 Annotations EJB 3.0 JPA JSF JAXB JAX-WS 開発容易性 Java EE 6 JAX-RS CDI Servlet 3.0 Web Profile Pruning 軽量化 1999 2001 2003 2006 2009 2013 Java EE 7 JAX-RS 2.0 JSON-P WebSocket JMS 2.0 Batch 生産性 & HTML5 J2EE 1.2 Servlet JSP EJB JMS エンタープライズ アプリケーション Java EE 8 – The Next Step Java EE 8 Servlet 4.0 JAX-RS 2.1 JSON-B JSON-P 1.1 Security モダナイゼーション シンプル化 2017