Cozyモデル駆動開発/ビジネス・コンテキスト

「ブックカフェ併設のセレクトショップ販売店」のシステム開発のプロジェクトを進めています。

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール

今回はビジネス・コンテキスト図を作成します。

「ブックカフェ併設のセレクトショップ販売店」の名前をPieris Booksとします。

ビジネス・コンテキスト図

Pieris Booksのビジネス文脈を以下の観点からビジネス・コンテキスト図で記述します。

• ビジネスの境界を定める
• サービス利用者
• サービス提供者
• 使用する外部サービス

このビジネス・コンテキスト図はシステム開発のためのビジネス文脈を明確にするために、ビジネス・オーナーにヒアリングしながら開発側で作成しものです。抜けなどがある可能性はありますが、まずは起点となる土台を明確化する目的です。開発中に抜けなどが分かれば、随時追加していく想定です。

この結果作成したビジネス・コンテキスト図は以下になります。

ビジネス境界

ビジネス境界として、ビジネス・システムPierisBooksを作成しました。ステレオタイプにbusinessを設定しています。

ビジネス・システムPierisBooks内に以下の3つのビジネス・サブシステムを定義しました。

• EC
• 店舗
• 在庫管理

PierisBooksに関係する各種アクターを定義しています。

サービス利用者

PierisBooksのサービス利用者は以下の2つのアクターです。

• EC利用者
• 店舗利用者

利用者に対してECの口と実店舗の口を持っているので、それぞれの利用者をアクターとして記述しました。

EC利用者と店舗利用者が同じケースもあると思いますが、そのあたりのモデリングは後のフェーズで行う予定です。ここでは、ビジネス・システムの文脈がざっくりつかむことを優先しています。

サービス提供者

PierisBooksのサービス提供者は以下の3つのアクターです。

• 店舗運営者
• 販売管理者
• システム管理者

PierisBooksの運営・管理を行うロールですが、ビジネスのレイヤーによってさまざまなロールがあります。

店舗運営者はビジネス上の店舗運営を行います。販売管理者は商品の管理などを行います。

システム管理者はビジネスとは距離をおいた形でITシステムの管理を行います。

使用する外部サービス

PierisBooksが使用する外部サービスは以下の3つのアクターとしてモデル化しました。

• 外部ECサービス
• 決済サービス
• 配送サービス

PierisBooksでは商品のショーケースとしての運営を行います。このため利用者が商品の購入を考えた場合には、PierisBooksのシステムを経由して外部ECサービスに販売・配送を依頼します。

決済サービスは店舗に在庫があった場合のECや店舗での購入で使用する想定です。

配送サービスは店舗在庫の配送を依頼します。

外部ECサービスと決済サービス、配送サービスは一部機能が重なるのでケース・バイ・ケースで使い分けることになるでしょう。このあたりの具体的な処理は今後のモデリングで考えていくことにします。

用語集

ビジネス・コンテキスト図に登場する用語をまとめて用語集を作成します。

種別には以下のものが入ります。

BS

Business System

BA

Business Actor

用語	種別	意味
Pieris Books	BS	Pieris Booksビジネス全体
EC	BS	Pieris BooksのEC機能
店舗	BS	Pieris Booksの実店舗
在庫管理	BS	実店舗での在庫管理
EC利用者	BA	ECサイトの利用者
店舗利用者	BA	店舗の利用者
外部ECサービス	BA	見本品を購入する際に使用する外部のECサービス
決済サービス	BA	ECまたは店舗での商品販売に使用する決済サービス
配送サービス	BA	ECでの商品販売を依頼する配送サービス
店舗運営者	BA	ビジネス上の店舗運営を行う
販売管理者	BA	店舗での商品管理などを行う
システム管理者	BA	Pieris BooksのITシステムの管理を行う

まとめ

今回はビジネス・コンテキスト図のたたき台を作成しました。

次回は、ビジネス・コンテキストをCozyで取り扱う方法について考えます。

Cozyモデル駆動開発/ビジネス・ゴール

前回はプロジェクトのターゲットとなるビジネスとして「ブックカフェ併設のセレクトショップ販売店」そのビジネス・ビジョンを定義しました。

今回はビジネス・ゴールを定義します。

背景

ビジネス・ゴールを考える上で難しいのが本開発におけるビジネス・オーナーの立ち位置です。

本開発のビジネス・オーナーだあるブックカフェオーナーはITには疎く、本開発ではA君がヒアリングしながらビジネス・モデルを作成しています。このため、大企業のCEOが作成するような詳細なビジネス・モデルを作成して、これをベースにソフトウェア開発を進めるということは考えられません。

ここではソフトウェア開発に必要な指針レベルのざっくりしたものを、あまり時間をかけずに作成する 方針にしましょう。

また現段階では、ソフトウェア開発のフェーズはインセプション・フェーズなので、まずはたたき台レベルのビジネス・モデルにしておいて先を進めることを優先するのも合理的です。

アプローチ

前回挙げた開発システム概要をまとめると以下になります。

• 新刊・古本の販売も行うブックカフェだったが、新しくアクセサリーや日用品のセレクト商品販売を併設することになった
• このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式
• 見本品はECサイトでの販売も行う
• 見本品中心ではあるが小型の品は少量の在庫を持って即時販売も可能

この情報を元にビジネス・ゴールを考えていきましょう。

KGI/KPI

ビジネス・ゴールを考える上で重要な概念がKGIとKPIです。

• KGI : Key Goal Indicator
• KPI : Key Performance Indicator

KGIはビジネス上のゴールとなる指標で、売上高や粗利益といった会計などを中心とした目標を使うのが一般的です。

ただ、売上高や粗利益といった大きな枠組みの目標では、日々のビジネス活動に直接当てはめることは難しいので、中間目標としてビジネスのパフォーマンスの指標であるKPIを導入します。

つまり一つのKGIに対して、KGIを達成するための中間目標であるKPIが複数存在するという親子関係になります。

本来はこのKGI/KPIをビジネス・ゴールに盛り込みたいところです。

ただ、ビジネス・オーナーはもちろん最終的な収益には関心がありますが、KGIやKPIといったような指標化にはあまり興味がないようです。まだインセプション・フェーズでもあるので、システムが動作して大まかな状況が見えてくるまでKGI/KPIについては保留にすることにします。

ビジネス・ゴール

今回は作業を進めるためにざっくりという方針で以下のビジネス・ゴールにしてみました。

- ブックカフェにセレクト商品販売を併設
- セレクト商品は(1)店舗在庫あるものは直接販売、(2)店舗在庫のないものはECで販売、(3)WebのECサイトでEC販売

ビジネス・ゴールはMarkdown形式で記述しています。前回挙げた開発システム概要をまとめたレベルのものですが、まずはここからざっくり始めたいと思います。

保存

ビジネス・ゴールは src/main/cozy/business 配下に goal.md として格納します。

まとめ

今回は開発システム概要を元にビジネス・ゴールを作成しました。本来はビジネス・オーナーが作成するのが理想ですが、システム開発を進めるためにビジネス・オーナーにヒアリングしながら開発側で作成したものになっています。

次回もビジネス・モデルの作成を続けます。

Cozyモデル駆動開発/ビジネス・ビジョン

ビジネスで必要とされるソフトウェア・システムの開発を開始するにあたって、ソフトウェア・システムを利用するビジネス側の文脈を明確にしておく必要があります。

ビジネス側の文脈のモデルとしてビジネス・モデルを作成しますが、今回はその最初としてビジネス・ビジョンを作成します。

インセプション・フェーズ

UP(Unified Process)にならってソフトウェア開発のフェーズを以下の4つと考えることにします。

• インセプション・フェーズ (Inception phase)
• エラボレーション・フェーズ (Elaboration phase)
• コンストラクション・フェーズ (Construction phase)
• トランジッション・フェーズ (Transition phase)

インセプション・フェーズは、システム開発の方向性を確定するためのフェーズで、仮設に基づく実装を行いその結果を評価します。

エラボレーション・フェーズでは、複数のイテレーションで開発を勧めながらシステムの最終型に向けて必要な技術要素を決めていきます。

これらの作業の結果を受けて、コンストラクション・フェーズでは具体的な肉付けを行っていきます。

一通り開発が終了した後、トランジッション・フェーズではプロジェクトのクロージングや保守体制への以降を行います。

今回からプロジェクトの立ち上げとなるインセプション・フェーズの活動を進めていきます。

開発システムの概要

今回の開発ターゲットはブック・カフェの販売システムです。

このブック・カフェでは、新刊・古本などの書籍に加えてアクセサリーや日用品などのセレクト商品の販売をしています。

もともと新刊・古本の販売も行うブックカフェでしたが、新しくアクセサリーや日用品のセレクト商品販売を併設することにしました。

このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式を主に考えています。また見本品はECサイトでの販売も行います。

とはいえ、見本品中心ではありますが小型の品は少量の在庫を持って即時販売も可能にしたいと考えています。

開発体制

以下の開発体制を想定しています。

• フロントエンド開発者 1人
• バックエンド開発者 1人
• ブックカフェオーナー 1人 (発注者)

ブックカフェオーナーのX氏から個人でシステム開発を受注したA君がバックエンド開発を行い、フロントエンドエンジニアのB君にUI開発を依頼するという体制です。

ブックカフェオーナーはITには疎いので、A君がヒヤリングを行いながら自前でビジネス・モデルと要求モデルを作成していく想定です。

フォーマット

ビジョンの記述には以下のフォーマットを使用することにします。

FOR ターゲット顧客
WHO 利用者
THE 製品名 is a 製品カテゴリ
THAT キーとなるメリット、製品を買う理由
UNLIKE 競合商品
OUR PRODUCT 競合商品との違い

このフォーマットを使ってビジネス・モデルのビジョンとシステムの要求モデルのビジョンの2種類を作成していきます。

ビジネス・ビジョン

ビジネス・システムのモデルでは、ビジネスそのもののビジョンをビジネス・ビジョンとして定めます。

X氏と話し合って以下のビジネス・ビジョンを定義しました。X氏はこういったドキュメントの作成に乗り気ではありませんので、ソフトウェア開発側で意識するビジョンとしてメモ的に作成したものです。今後の開発で随時調整していくことを想定しています。

FOR セレクトショップ販売店
WHO 本を読みながらカフェでのんびりしたい人
THE BCwSG is a ブックカフェ併設のセレクトショップ
THAT カフェの利用者にセレクト商品の紹介と販売を行うことができる
UNLIKE 通常のセレクト・ショップ
OUR PRODUCT ブック・カフェを併設することで商品の販売機会を増やすことができる

まずブックカフェ併設のセレクトショップの名前を仮にBCwSG(Book Cafe With Select Goods)と決めました。

ターゲットとなる利用者を「本を読みながらカフェでのんびりしたい人」とし、セレクトショップ販売店に「カフェの利用者にセレクト商品の紹介と販売を行うことができる」ことをビジネス上の価値としました。

これが通常のセレクト・ショップに対するアドバンテージと考えています。

保存

ビジネス・ビジョンは src/main/cozy/business 配下に vision.txt として格納します。

まとめ

今回からブックカフェ併設のセレクトショップBCwSGを題材に具体的なモデリングを進めていきます。

インセプション・フェーズの最初のモデルとしてビジネス・ビジョンを作成しました。

モデリングを行いながら各作業分野で定義していくモデルを明らかにしていきたいと思います。

Cozyモデル駆動開発/成果物の管理

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみます。

ファイル構成

図はCozyモデル駆動開発におけるプロジェクトのファイル構成の案です。

プログラムはScalaによる記述を想定しているのでsbtのファイル構成を踏襲しています。

srcディレクトリの配下に以下のディレクトリを配置します。

main

メインのソースコード

test

テストのソースコード

さらにmain配下に以下のディレクトリ配置します。

cozy

Cozyモデル

scala

Scalaプログラム

以下でそれぞれの内容について説明します。

Cozyモデル

src/main/cozyディレクトリにCozyモデルを格納します。

Cozyでは、Cozyモデルと後述のScalaモデルの両方のコンテンツの情報を統合してプロジェクトのCozyモデルを作成します。

CozyモデルはScalaモデルで記述しきれない仕様をCozy形式で記述します。

cozyディレクトリには以下のディレクトリを配置します。それぞれのディレクトリが対応するモデルを格納します。

• business : ビジネス・モデル
• requirement : 要求モデル
• analysis : 分析モデル
• design : 設計モデル

ビジネス・モデル

businessディレクトリにはビジネス・モデルを格納します。

ソフトウェア開発におけるビジネス・モデルでは、開発するソフトウェアのビジネス上の位置づけや用途などのビジネス文脈を記述します。

ビジネス・システムを駆動するビジネス・モデルを作成し、これをソフトウェア開発の入力にするのが理想ですが、そのような本格的なアプローチが取れない場合はソフトウェア開発に必要な範囲でビジネス文脈を整理するのがよいでしょう。

前回はEssenseのアルファとしてビジネス・システム・アルファとして定義しました。

記述するモデルの候補としては以下のものが考えられます。

• ビジョン
• ゴール
• ビジネス・コンテキスト
• ビジネス・ユースケース
• ドメイン・モデル

また、ビジネスの計測と結果のフィードバック・ループに対応するため以下のモデルについても扱っていく予定です。

• KGI(Key Goal Indicator)
• KPI(Key Performance Indicator)

モデルは基本的には通常ファイルに自然言語のテキストとして記述する形になりますが、コンテキスト・モデルは図として記述するのが適切なので、これをどのように記述するのかは工夫が必要そうです。

要求

requirementディレクトリには要求モデルを格納します。

記述するモデルの候補としては以下のものが考えられます。

• ビジョン
• ゴール
• コンテキスト・モデル
• ユースケース

ビジョン、ゴール、コンテキスト・モデル、ユースケースはビジネス・モデルと同じ項目ですが、開発対象となるソフトウェア・システムのビジョン、ゴール、コンテキスト・モデル、ユースケースという点が異なります。

またビジネス・モデルで定義したKGIやKPIも、必要に応じて要求モデルに引き継がれるでしょう。

モデルの記述方法はビジネス・モデルと同様に通常ファイルに自然言語で記述するものが中心となります。

分析

analysisディレクトリには分析モデルを格納します。

作業分野「分析」と「設計」はEssense標準ではShape the Systemアクティビティ空間に所属するアクティビティということになるでしょう。

分析はPIM(Platform Independent Model)を、設計はPSM(Platform Specific Model)を記述するというモデルの抽象度に違いがあります。

しかし、実装主導の開発では開発ではPIMを意識しつつPSM主体の設計になると思うので、実務的には要求から直接設計に進み、必要に応じて分析も行う、というところが実際のところかもしれません。この点も加味して分析について検討していく予定です。

設計

designディレクトリには設計モデルを格納します。

設計モデルでは、実装に直結したモデルを構築します。

設計モデルを考える上で重要なのはプログラム自身が設計になっているといる点です。特にオブジェクト指向プログラミングで記述した場合には、オブジェクト・モデルとのインピーダンス・ミスマッチが低いので、場合によってはそのままモデルと考えてもよいかもしれません。

しかし、プログラミングの場合はプログラム動作上のさまざまな処理を追加していくため、抽象的なモデルとずれてきたり、境界が曖昧になってきます。この問題に対応するためアノテーションの仕組みを使ってモデルとして扱う箇所とモデルとして位置づけを記述していくことになるでしょう。また、JavaやScalaではプログラム内に仕様を自然言語で記述する仕組みがあるので、これを用いてより詳細にモデルの情報を記述することができます。

すべてのモデルをアノテーション付きプログラムで記述することはできないので、この記述できない部分は別の形でモデルを記述することになります。

一つはドメイン・モデルなど定型化して形式で記述したモデルです。

このモデルからはインタープリタで直接実行したり、実装を自動生成することができます。

最後にアーキテクチャ全体の情報やコンポーネントやクラスなどの仕様に関して自然言語による記述を行う場合があります。このような記述は通常ファイルに記述した上でプログラム・モデルと統合して設計モデルを組み上げていくことになるでしょう。

Scalaプログラム

本シリーズではプログラミング言語にScalaを用います。

Scalaプログラムとして開発するソフトウェアの本体のプログラムとテスト・プログラムを作成します。

本体

開発ターゲットの本体のScalaプログラムはsrc/main/scalaディレクトリに格納します。

前述したようにScalaプログラムにアノテーションとScaladocを併用することで、モデルとして扱うことができます。

プログラミング言語としてScalaを使用するので、Scaladoc形式でインタフェース仕様を記述します。

Cozyは、モデル、プログラム、テスト・ケースからそれぞれに記述された仕様を集め、マージしたものをプロジェクトの仕様として統合します。

テスト

Scalaによるテスト・プログラムはsrc/test/scalaディレクトリに格納します。

Cozyモデル駆動開発ではTDD(Test-Driven Development)、BDD(Behavior-Driven Development)でテストを動く仕様(executable specification)として扱っていきます。

これはテストを要求仕様、コンポーネント仕様として作成して活用していくという意図があります。

この場合は、自然言語で記述した要求モデルとどのように連携していくのかがポイントとなるでしょう。

TDD, BDDの基盤としてscalatestを使用する想定です。

まとめ

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみました。

次回はビジネス・モデルについて具体的に考えていく予定です。

Cozyモデル駆動開発/ビジネス・モデリング

モデル駆動開発ワークベンチCozyを使用したモデル駆動開発を具体的に考えて、Cozyへの機能要件を洗い出しています。

Cozyを使用したモデル駆動開発をCozyモデル駆動開発 (Cozy Model-Driven Development)、略してCMDDと呼ぶことにします。

ビジネス・モデリングの位置付け

まず最初の作業分野はビジネス・モデリングです。

ビジネス・モデリングの関心分野の候補としては、カスタマー(Customer)とソルーション(Solution)が考えられます。

Essenceカーネルではカスタマーには以下のアルファが定義されています。

• ステークホルダー(Stakeholders)
• 機会(Opportunity)

またソルーションには以下のアルファが定義されています。

• 要求(Requirements)
• ソフトウェア・システム(Software System)

ビジネス・モデリングをどの関心分野のどのアルファにどのような形で組み込むかは、開発プロセス内でのビジネス・モデリングの目的によって変わってくるところでしょう。

CMDDでは小規模チームで、中小規模アプリケーションまたは大規模アプリケーションのサブシステムの開発をターゲットにします。

ビジネス・モデリングは要求アルファの入力の情報になるものなので、ソルーションの補助的な活動と考えると要求アルファにアクティビティと成果物を追加するアプローチも考えられます。

また、ビジネス・モデリングはソルーションの外側、カスタマー側の情報と考えるとカスタマー側に配置することも考えられます。その場合はステークホルダー、機会といったアルファに入れるよりも、新しくビジネス・モデリングを行うアルファを追加するのがよさそうです。

今回は関心分野カスタマーに新規のアルファとしてビジネス・システム・アルファを追加して検討を進めることにします。

ビジネス・システム・アルファ

ビジネス・モデリングではビジネス・システムをモデリングします。

このビジネス・システムをモデリングするアルファをビジネス・システム・アルファとします。ビジネス・システム・アルファの成果物(Work Product)として以下のモデルを考えます。具体的なモデルを作ってみて調整していく予定です。

• ビジョン
• ビジネス・コンテキスト
• ビジネス・ユースケース
• ドメイン・モデル

ビジョン

ビジョン(Vision)はプロジェクトのビジネス・システム上のビジョンです。

プロジェクトの全体の方向性を定めます。

このビジョンをベースに、要求アルファでソフトウェア開発上のビジョンを定める想定です。

ビジネス・コンテキスト

ビジネス・システムのおかれている環境をビジネス・コンテキストとしてモデル化します。

ビジネス・システムと関係する外部組織の存在とインタラクションを明確にします。

ビジネス・ユースケース

ビジネス・ユースケース(Business UseCase)はビジネス・システムにおけるユースケースです。

ビジネス・コンテキストの舞台の上で、ビジネス・システムの各種利用者が体験する物語を記述します。

開発対象のソフトウェア・システムはこの物語の中に登場し、物語の遂行を助けます。

要求アルファで作成する(システム)ユースケースは、ビジネス・ユースケースの物語の中での利用方法を切り口に・ソフトウェア・システムと利用者の対話の物語を記述することになります。

ドメイン・モデル

ドメイン・モデル(Domain Model)はソフトウェア・システムの操作対象となる問題領域(problem domain)のモデルです。

ドメイン・モデルはビジネス・システムとソフトウェア・システムで一本化したいので、その方向で検討を進めます。

ただ、ビジネス・システムとソフトウェア・システムのモデルの規模が違いすぎる場合は別立てで管理した方がよいかもしれません。そのあたりの考察も進めていきたいと思います。

まとめ

今回は要求アルファの入力となるビジネス・モデリングの扱いについて考えてみました。

ここでは、関心分野カスタマー側にビジネス・システム・アルファとして入れることにしましたが、その是非は今後の考察で検討していきたいと思います。

次回は、ビジネス・システム・アルファの具体的な検討に入る前に、モデルなどの成果物の管理方法について検討します。

Cozyによるモデル駆動開発

モデル駆動開発のエコシステムを支えるキーパーツとして、Webアプリケーション・フレームワークのCozy Webを開発してきました。

今回からCozyを使用したモデル駆動開発について具体的に考えていきたいと思います。

Cozyは現在開発途中ですが、モデル駆動開発に必要な機能を拡張していく上でどのような機能が必要かの洗い出しが目的です。要求モデルにおけるユースケース分析的なアプローチですね。

EssenceというOMGが標準化している開発方法論フレームワークの枠組み、用語を使用して考えていくことにします。

実際の検討に入る前に、今回は開発方法論を記述する言語として使用するEssenceについてみていきます。

Essence

EssenceはSoftware Engineering Methods and TheoryとObject Management Group®によって作成された開発方法論のフレームワークです。

• https://www.omg.org/spec/Essence/

Essenceでは開発方法論を記述する言語(Language)と基本的な枠組み(Kernel)を定めており、この骨組みにプラクティスで肉付けすることで開発方法論を定義します。

Essenceの言語では、従来のモデリングの用語に加えて、新しい用語が導入されています。その点も含めて用語の整理をします。

基本概念

アルファ

アルファ(alpha)は開発作業を進める上で必要な各種概念を表現したものです。アルファの具体例として要求(requirement)やソフトウェア・システム(software system)があります。

アルファに対応する日本語用語はないと思うので、本Blogではアルファの用語を使います。

ワーク・プロダクト

ワーク・プロダクト(work product)はソフトウェア開発の各種成果物です。

ワーク・プロダクトの例としては要求仕様(要求アルファ)やコード(ソフトウェア・システム・アルファ)があります。

アクティビティ

アクティビティ(activity)はソフトウェア開発の活動を表現します。

アクティビティの例としては「ミーティングを開く(Holding a meeting)や「コードを書く(Writing Code)」があります。

アクティビティ・スペース

アクティビティ・スペース(activity space)はソフトウェア開発の活動分野を表現したものです。

アクティビティ・スペース内でアクティビティが実行されます。

アクティビティ・スペースの例としては「ステークホルダー・ニーズを理解する」や「システムを実装する」などがあります。

コンピテンシィ

コンピテンシィ(competency)は作業を進めるのに必要な各種能力です。

コンピテンシィの具体例としてはステークホルダー代表(カスタマー関心分野)や開発(ソルーション関心分野)などがあります。

関心分野

Essenceではソフトウェア開発の関心分野(area of concern)として以下の3つを定義しています。

• カスタマー
• ソルーション
• エンデバー

Essenceのアクティビティはこの関心分野のどれかに所属することになります。

カスタマー

カスタマー(customer)はソフトぅエア・システムの利用方法についての関心分野です。

Essenceカーネルではカスタマーの関心分野で以下のアルファを定義しています。

• ステークホルダー (stakeholder)
• 機会 (opportunity)

また以下のアクティビティ・スペースを定義しています。

• 可能性を探る (Explore Possibilities)
• ステークホルダー・ニーズを理解する (Understand Stakeholder Needs)
• ステークホルダーの満足を確保する (Ensure Stakeholder Satisfaction)
• システムを利用する (Use the System)

ソリューション

ソルーション(solution)はソフトウェアの実現に関しての関心分野です。

Essenceカーネルではソルーションの関心分野で以下のアルファを定義しています。

• 要求 (requirement)
• ソフトウェア・システム (software system)

また以下のアクティビティ・スペースを定義しています。

• 要求を理解する (Understand the Requirements)
• システムを形作る (Shape the System)
• システムを実装する (Implement the System)
• システムをテストする (Test the System)
• システムを配備する (Deploy the System)
• システムを運用する (Operate the System)

エンデバー

エンデバー(endevor)は直訳すると「努力」ですが、ここではチームが努力して進める活動というような意味合いから選ばれた用語ではないかと思います。

エンデバーに対応する日本語用語はないと思うので、本Blogではエンデバーの用語を使います。

Essenceカーネルではソルーションの関心分野で以下のアルファを定義しています。

• チーム (team)
• ワーク (work)
• 仕事の進め方 (way of working)

また以下のアクティビティ・スペースを定義しています。

• ワークの準備をする (Prepare to do the Work)
• アクティビティを協調させる (Coordinate Activity)
• チームをサポートする (Support the Team)
• 進捗を追尾する (Track Progress)
• ワークを止める (Stop the Work)

まとめ

本ブログでCozyを使用したモデル駆動開発に対する分析を始めることにしました。

開発プロセスを記述するためのフレームワークとしてOMGのEssenceを使用します。今回はその準備としてEssenceの用語の整理をしました。

次回はビジネス・モデリングんいついて考えます。

Cozy Web/グリッド内カードのカスタマイズ

モデル駆動開発のエコシステムのキーパーツとして、Webアプリケーション・フレームワークのCozy Webを紹介しています。

前回はWebフロントエンド・フレームワークBootstrapの上でグリッド表示を行いました。

今回はグリッド内に配置されるカードをカスタマイズする方法について説明します。

HelloGrid

前回作成したリソースのグリッド表示を行うHelloGridを使用します。

HelloGridはBootstrap 5を使ってグリッド表示を行います。

Cozy Web/Webライブラリで紹介したWebライブラリ機能を使用してBootstrap 5をサポートするBootstrap5ライブラリを使用しています。

準備

cozyを起動するディレクトリのwebappsディレクトリに、アプリケーションのホームディレクトリとなるHelloGridを作成します。

モデル

WEB-INF/models/model.orgにアプリケーションで使用するモデルが定義します。これはHelloResourceと同じ設定です。

* entity  
** product
*** features  
table=product
*** attributes  
| Name  | Type   | Multiplicity |
|-------+--------+--------------|
| id    | token  |            1 |
| name  | string |            1 |
| price | int    |            1 |

エンティティproductを定義しており、Webのリソースproductとなります。

webapp.conf

ホームディレクトリのWEB-INFディレクトリ配下にwebapp.confを配置し、Bootstrap5ライブラリの名前である「bootstrap5」をextend属性に設定します。この設定を行うことで、Bootstrap5ライブラリがWebアプリケーションのベースとして設定されます。

またthemeにbootstrap-gridを設定します。この設定により一覧表示がグリッドで表示されます。

ここまでが前回の設定です。

extend: bootstrap5
theme: bootstrap-grid

今回はグリッドの表示方法をカスタマイズします。

このためにwebapp.confに以下のようにrender.card_kind_in_gridを設定します。

render.card_kind_in_gridに"grid"を指定しているので、card__gridという名前のウィジェットがグリッド内のカードの表示に使用されます。

extend: bootstrap5
theme: bootstrap-grid
render.card_kind_in_grid: "grid"

カードの表示内容の設定

グリッド内にカードを表示するときに使用するウィジェットcard_gridを作成します。

以下のJade形式の card__grid.jade 作成し、WEB-INF/widgets配下に配置します。

-@val card: ViewCard
div.card
  div.card-header
    h4.card-title
      =card.header

ファイル名card__grid.jadeの「card」はウィジェット種別を表しこの場合はカードを示します。「__」の後のgridはウィジェットの名前を表します。

カードを記述するDIV要素以下をカードの部品として定義しています。部品内ではHTMLの要素を自由に使うことができます。

部品内のHTML要素ではBootstrapで定義されているcard, card-header, card-titleといったクラス属性を指定しているので、Bootstrapによって適切な表示が行われます。

また、カードの表示に必要な情報はViewCardオブジェクトとして渡されてくるので、ここから必要な情報を取り出してウィジェット内のHTML要素に埋め込んでいきます。ここではカードのヘッダ情報をH4要素に入れています。

グリッド表示

それでは、グリッド表示を行います。

Webブラウザ

productリソースに対するアクセスを行います。

http://localhost:8080/web/HelloGrid/product

webページの表示のために出力されたHTML文書は以下になります。

<?xml version="1.0"?>
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="utf-8"/>
    <meta content="width=device-width, initial-scale=1" name="viewport"/>
    <link crossorigin="anonymous" integrity="sha384-1BmE4kWBq78iYhFldvKuhfTAU6auU8tT94WrHftjDbrCEXSU1oBoqyl2QvZ6jIW3" rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/css/bootstrap.min.css"/>
    <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap-icons@1.10.0/font/bootstrap-icons.css"/>
    <style>
      .card a {
      color: inherit;
      text-decoration: none;
      }
      .card:hover {
      background-color: #f8f9fa;
      border-color: #007bff;
      }
    </style>
  </head>
  <body>
    <script crossorigin="anonymous" integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstrap.bundle.min.js"/>
    <nav class="navbar navbar-light bg-primary">
      <div class="container-fluid">
        <span class="navbar-brand mb-0 h1">Cozy Web</span>
      </div>
    </nav>
    <nav class="navbar navbar-expand-lg navbar-light bg-light">
      <div class="container-fluid">
        <a class="navbar-brand" href="#">Navbar</a>
        <button class="navbar-toggler" type="button" data-bs-toggle="collapse" data-bs-target="#navbarNav" aria-controls="navbarNav" aria-expanded="false" aria-label="Toggle navigation">
          <span class="navbar-toggler-icon"/>
        </button>
        <div class="collapse navbar-collapse" id="navbarNav">
          <ul class="navbar-nav">
            <li class="nav-item">
              <a class="nav-link active" aria-current="page" href="#">Home</a>
            </li>
            <li class="nav-item">
              <a class="nav-link" href="#">Features</a>
            </li>
            <li class="nav-item">
              <a class="nav-link" href="#">Pricing</a>
            </li>
            <li class="nav-item">
              <a class="nav-link disabled" href="#" tabindex="-1" aria-disabled="true">Disabled</a>
            </li>
          </ul>
        </div>
      </div>
    </nav>
    <div class="container">
      <div class="row">
        <div class="col-12 col-sm-6 col-md-3 col-lg-2 col-xl-1">
          <div class="card">
            <div class="card-header">
              <h4 class="card-title">
          Apple
        </h4>
            </div>
          </div>
        </div>
        <div class="col-12 col-sm-6 col-md-3 col-lg-2 col-xl-1">
          <div class="card">
            <div class="card-header">
              <h4 class="card-title">
          Orange
        </h4>
            </div>
          </div>
        </div>
        <div class="col-12 col-sm-6 col-md-3 col-lg-2 col-xl-1">
          <div class="card">
            <div class="card-header">
              <h4 class="card-title">
          Peach
        </h4>
            </div>
          </div>
        </div>
        <div class="col-12 col-sm-6 col-md-3 col-lg-2 col-xl-1">
          <div class="card">
            <div class="card-header">
              <h4 class="card-title">
          Berry
        </h4>
            </div>
          </div>
        </div>
      </div>
    </div>
    <nav class="navbar navbar-light bg-secondary">
      <span>Cozy Web</span>
    </nav>
  </body>
</html>

前回のグリッド表示ではカード部分は以下のHTML断片になっていました。

          <div class="card">
            <a href="product/1.html" class="">
              <img src="assets/img/no-image-icon.png" class="card-img-top"/>
              <div class="card-header">
                <h4 class="card-title">Apple</h4>
              </div>
            </a>
          </div>

今回は、以下のHTML断片になっており、グリッド内のカードはcard__grid.jadeで定義したものが使用されています。

          <div class="card">
            <div class="card-header">
              <h4 class="card-title">
          Apple
        </h4>
            </div>
          </div>

まとめ

Cozy Webでリソースの定義をすることで、Webアプリケーションが簡単に作成できることを確認してきました。

今回はBootstrapによるレスポンシブル・デザインによるグリッド表示のカードをカスタマイズする方法について説明しました。

モデルの定義とカスタマイズしたカードの定義以外はほとんどノープログラミングでレスポンシブルなWebアプリケーションの作成ができることを確認することができました。

諸元

Cozy

0.0.16