【案内】小説『エクストリームセンス』について

　小説『エクストリームセンス』は、本ブログを含めていくつか掲載していますが、PC、スマフォ、携帯のいずれでも読みやすいのは、「小説家になろう」サイトだと思います。縦書きのPDFをダウンロードすることもできます。

　小説『エクストリームセンス』のURLは、 http://ncode.syosetu.com/n7174bj/

ラベル UML の投稿を表示しています。 すべての投稿を表示
ラベル UML の投稿を表示しています。 すべての投稿を表示

2012年11月26日月曜日

Enterprise Architect で小説のストーリー設計

ラベル: , , , , , , ,

　現在、小説『エクストリームセンス』の第2部を執筆中ですが、私の場合は、UMLモデリングツール「Enterprise Architect」を使い、下図のようにストーリーを設計しています。
　こうすると、小説の登場人物、組織、概念、イベントなどの静的側面を視覚化できます。つまり、小説のプロットです。

　モデル駆動小説設計、とか……

 

ESStoryDesign
ESStoryDesign posted by (C)Satohru

0 コメント

2011年9月30日金曜日

簡単なソフトウェアを作ってみよう(5)

ラベル: , , , , , , , ,
今日は、先に紹介したVB.NETのソースコードをEnterprise Architectでリバースしたクラスモデルを掲載します。

ClassModel
ClassModel posted by (C)Satohru

Employeeを永続化するXMLファイルはこんな感じです。


1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
<?xml version="1.0" encoding="utf-8"?>
<root>
  <employee>
    <id>4</id>
    <name>たちつてと</name>
    <birthday>1957/07/11</birthday>
    <postid>1</postid>
  </employee>
  <employee>
    <id>88</id>
    <name>あいうえお</name>
    <birthday>1939/03/24</birthday>
    <postid>1</postid>
  </employee>
</root>


0 コメント

2011年9月10日土曜日

簡単なソフトウェアを作ってみよう(3)

ラベル: , , , , , ,
久しぶりの本連載。画面はちょっと変更しました。

簡単なソフトウェアを作ってみよう(3)
簡単なソフトウェアを作ってみよう(3) posted by (C)Satohru

データ表示部をListBoxからDataGridViewに変更し、データにユニークキーを持たせました。

このソフトウェアのデータを保持するのが、employeeクラス。
こんな感じです。

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
Public Class employee
‌ 
    Private _id As Integer
    Private _name As String
    Private _birthday As Date
    Private _PostID As Integer
‌ 
    '==============
    'IDプロパティ
    Public Property ID() As Integer
        Get
            Return _id
        End Get
        Set(ByVal value As Integer)
            _id = value
        End Set
    End Property
‌ 
    '==============
    'Nameプロパティ
    Public Property Name() As String
        Get
            Return _name
        End Get
        Set(ByVal Value As String)
            _name = Value
        End Set
    End Property
‌ 
    '==============
    'Birthdayプロパティ
    Public Property Birthday() As Date
        Get
            Return _birthday
        End Get
        Set(ByVal Value As Date)
            _birthday = Value
        End Set
    End Property
‌ 
    '==============
    'Ageプロパティ
    Public ReadOnly Property Age() As Integer
        Get
            '誕生日後の年齢をセット。
            Dim _age As Integer = _
                CType(Today.ToString("yyyy"), Integer) - _
                CType(_birthday.ToString("yyyy"), Integer)
            '現在月日が誕生月日よりも小さければ誕生日前なので-1歳。
            If CType(Today.ToString("MMdd"), Integer) < _
                CType(_birthday.ToString("MMdd"), Integer) Then
                _age = _age - 1
            End If
            Return _age
        End Get
    End Property
‌ 
    '==============
    'PostIDプロパティ
    Public Property PostID() As Integer
        Get
            Return _PostID
        End Get
        Set(ByVal value As Integer)
            _PostID = value
        End Set
    End Property
‌ 
End Class

そして、employeeクラスを束ねるコレクションクラスがEmployeeCollectionクラス。

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
Public Class EmployeeCollection
‌ 
    Inherits System.Collections.CollectionBase
    Private da As New DataAccess
‌ 
    '==============
    'addメソッド
    Public Sub Add(ByVal id As Integer, ByVal name As String,
                   ByVal birthday As Date, ByVal postid As Integer)
        ' ID重複チェック
        If IDOverlap(id) = True Then
            MessageBox.Show("このIDはすでに登録されています。",
                            "登録エラー",
                            MessageBoxButtons.OK,
                            MessageBoxIcon.Error)
            Exit Sub
        End If
        'Add
        Dim _employee As New employee With {
            .ID = id,
            .Name = name,
            .Birthday = birthday,
            .PostID = postid
        }
        List.Add(_employee)
        da.DataCreate(_employee)
    End Sub
‌ 
    '==============
    'IDOverlapメソッド
    Private Function IDOverlap(ByVal ID As Integer) As Boolean
        'ID重複チェック
        Dim Response As Boolean = False
        Dim rs = From o As employee In List Where o.ID = ID
        If rs.Count = 1 Then
            Response = True
        End If
        Return Response
    End Function
‌ 
    '==============
    'removeメソッド
    Public Sub Remove(ByVal TargetEmployee As employee)
        Dim TargetIndex As Integer = _
            GetTargetIndex(TargetEmployee.ID)
        List.RemoveAt(TargetIndex)
        da.DataDelete(TargetIndex)
    End Sub
‌ 
    '==============
    'GetTargetIndexメソッド
    'コレクションのIndexを取得する。
    Public Function GetTargetIndex(ByVal ID As Integer) As Integer
        Dim TargetIndex As Integer
        Dim rs = From o As employee In List Where o.ID = ID
‌ 
        If rs.Count = 1 Then
            TargetIndex = List.IndexOf(rs.First)
        Else
            MessageBox.Show("IDが変更されています。",
                            "入力エラー",
                            MessageBoxButtons.OK,
                            MessageBoxIcon.Error)
            TargetIndex = -1
        End If
        Return TargetIndex
    End Function
‌ 
    '==============
    'Item Property
    Public Property Item(ByVal index As Integer) As employee
        Get
            Return CType(List.Item(index), employee)
        End Get
        Set(ByVal value As employee)
            List.Item(index) = value
        End Set
    End Property
‌ 
    '==============
    'Updateメソッド
    Public Sub Update(ByVal TargetEmployee As employee)
        Dim TargetIndex As Integer = _
            GetTargetIndex(TargetEmployee.ID)
        If TargetIndex = -1 Then Exit Sub
        List.Item(TargetIndex) = TargetEmployee
        da.DataUpdate(TargetIndex, TargetEmployee)
    End Sub
‌ 
    '==============
    'AveAge Property
    Public ReadOnly Property AveAge() As Double
        Get
            Dim rs = From o As employee In List Select o.Age
            Return rs.Average()
        End Get
    End Property
‌ 
    '==============
    'コンストラクタ
    Public Sub New()
        da.FileLoad(List)
    End Sub
‌ 
End Class
これがこのソフトウェアのコアドメインです。

続く…
0 コメント

昨日のツイートから

ラベル: , ,
  • 手続き型で書かれたソースコードをクラスを使ってリファクタリングしてみよう。「おおっ！ コードがカッコよくなった！」と感じたらオブジェクト指向を本格的に勉強したらいいと思うよ。 posted at 12:47:19
  • 9日前のツイート。 RT @Satohru: オブジェクト指向入門とかいうと、大抵はクラスの話から始まるが、これが入門者にとってよくないのでは？ 手続き型プログラムが分割され、よって責務が分割され、レイヤーが構築される。これによるメリットを最初に理解するべきだと思う。 posted at 12:51:43
  • オブジェクト指向にはソースコードからクラスモデルにリバースする手段が不可欠だと思う。私のおすすめはEnterprise Architect(UMLモデリングツール)。 posted at 12:59:40

0 コメント

2011年8月6日土曜日

業務改善プロジェクト　システム化構想立案～要件定義編

ラベル: , , , , , ,
　もう14年も見ている我が社の業務だから、どこをどう直すべきかは理解している。しかし、組織のアクションとして実現するためには、私の考えを社に示さなくてはならない。そこで、今回はバリューチェーンを使ってみた。

バリューチェーン
バリューチェーン posted by (C)Satohru

　このバリューチェーン分析によって、各部門の業務の性質やIT成熟度などがとても説明しやすくなり、私の作り上げたアクションプランは社のアクションとして承認された。
　そして2011年4月、具体的に物事を考え始めた。

仕事場
仕事場 posted by (C)Satohru

  1. IT化のスコープはできる限りコンパクトにして、ユーザーと開発者の負担を軽くしよう。
  2. 工程をいくつかのフェーズに分け、成果を確認しながら、成功（失敗）体験をユーザーと共に積み重ねながら進めて行こう。
  3. 今までと違う手法を試してみたい。今回はドメイン駆動設計を軸にしよう。
  4. ドキュメントはイントラネットに公開しよう。

　やるべきこと、やりたいことが湧き上がってくる。しかし、我が社が持つIT系人的リソースは私ひとり（3月までは部下がいたが、諸事情により退社した）。当然というべきか、計画どおり外部リソースを活用することになるのだが、問題はどう使うかだ。
 　SIerに丸投げする気など毛頭ない私は、派遣されてくるエンジニアと私の役割分担を考え、ドメイン駆動とユースケース駆動のツイン駆動だ！（？）、というアイデアにたどり着いた。こうすることで、要件定義手法RDRAの関係性の基づく網羅性の確保がより強固になると考えたのだ。

次期プロジェクトの要件定義手法
次期プロジェクトの要件定義手法 posted by (C)Satohru

 　このアイデアのもとSIerと協議し、結果としてふたりのSEと私の3人で今回のプロジェクトを開始することになった。
　
　6月。SIerのSEふたりは業務のフローに着目して分析を行い、業務フローからユースケースを導き出すことを最初のゴールと定めた。一方、私は業務の言葉やものに着目し、ドメインモデルとステートマシンモデルを作成した後、ステートマシンモデルのトリガーからユースケースを導き出した。

　プロジェクトを開始して2週間。私は重要なビジネスエンティティを発見した。これにより、業務のつながりがハッキリと見えるようになった。ドメイン駆動設計を意識したプロジェクトは今回が初めての経験だが、その有用性を十分に体感することができた。

　SEふたりの作業進捗はすばらしかった。モデリングはユースケースからロバストネスモデルの作成まで進み、その過程でラフなデータモデルもできあがっていた。また、私は最初の画面スケッチを手書きでノートに記していた。プロセスには拘らず、今考えるべきこと、今なすことが有効だと思われることをどんどんこなしていった。実に楽しいシステム開発である。

　それぞれが導き出したユースケースを突き合わせ、認識の違いや網羅性を確認していった。これがまた楽しく有用な作業となった。ドメイン駆動とユースケース駆動のツイン駆動。その有効性がこの作業で確認できた。ただし、プロジェクト特性を十分に考慮してこの手法は採用する必要がある。小規模でデータ集約型業務のシステム開発には、極めて有効なのではないだろうか。

　ひとまずユースケースが出そろったので、今後の計画作りのためにも、作ろうとしているシステムの規模を見積もることにし、ストーリーポイントによる規模見積もりを実施した。
　0、1、2、3、5、8、13の7枚のカードを3人が持ち、ユースケースに対する相対的な重みをカードを出すことによって示し合うのだ。意見が分かれたときには議論し、最終的にはチームの合意としてストーリーポイントを決める。
　これもまたエキサイティングな作業となった。この際の議論を通じ、ユースケースの突き合わせを行ったとき以上に、認識ギャップを埋めることに成功し、ユーザーにとって価値あることとは何かについて深く議論することができ、時には実装方法についても議論がおよんだ。

　規模の見積もりをすると、それに時間や単価という要素を加えて金額を見積もりたくなるのが人情である。サクッとSEが見積もったところ、32人月・4,000万円弱というような数字が出た。
　おいおい、ちょっと待ってくれ。仮に私ひとりでこのシステムを作るとして、32ヶ月もかかるわけがない。この意見にSEふたりも賛同してくれた。伝統的システム開発手法（請負契約によるウォーターフォール型開発など）は、知識の伝播を行う課程で相当の工数を消費する。そこでチームで議論し、このチームにPG2名を加えてアジャイルな開発をしようということになり、その後の私の再計画では5ヶ月・700万円くらいでリリースできるというシミュレーションがはじき出された。んーん、700万円かぁ。まだ高い…
　ということで、PGを外し、新たに採用する私の部下を加えた4人で開発していくプランを考えることとなった。

　そしてビジネス部門への最終提案。関係者を大会議室に集めて説明、質疑応答、議論と続いた。いい会だったと思う。ユーザーたちも主体的に業務のあり方を考えてくれている。

　このプロジェクトの最も大きな問題点は、直接的なユーザーである現場担当者と、間接的なユーザーとなるマネジメント層の関心事があまりにも違うということであり、私たち開発サイドの提案は、段階的にみんなの要求を実現していきましょうということである。
　業務においてどんな分析をするにしても、データがなければどうしようもない。マネジメント層が持つさまざまな関心事も、結局は現場担当者が作業することであり、それにはパワーシフトを起こさなければならない。
　今回提案したシステムは、いわば基礎工事である。基礎なくしてはどんな建物も建築することはできないのだから…　

　8月。プロジェクトは第2フェーズに入った。この続きはまた今度…
0 コメント

2011年6月5日日曜日

明日から新プロジェクト！

ラベル: , , , , , , ,
　明日から新しいプロジェクトが始まります。今回は、ある業務のシステム要件定義を進
めつつ、全社的な情報アーキテクチャーを整理しようとするものです。私と外部のエンジ
ニア2名によって、まずは7月中に最初の成果を出すことを目標としています。
　この業務を行うにあたって、私はユースケース駆動とドメイン駆動の両面からアプロー
チするという手法を考えました。
　私は主に問題領域の「もの」に着目し、ドメインモデリングを中心に分析を進めます。
外部のエンジニア2名は、主に問題領域の「こと」に着目して業務モデリングやユースケ
ースの抽出を中心に分析を進めます。そして、「もの」から発見されたビジネスエンティ
ティやトリガーなどと、「こと」から発見された情報やユースケースなどの整合性をチェ
ックすることで、新しい業務を正しく設計し、システム要件定義の網羅性を担保しようと
するものです。
　もちろん、要件定義の基本となる方法論はRDRAに準じて行います。さて、どうなるでし
ょうね？　明日からが楽しみです。
0 コメント

2011年4月23日土曜日

仕事場

ラベル: , , , ,
今日は震災で壊れたキャビネットのリプレース工事が行われ、ガンガン騒音が…
そんな中ドメイン分析をしておりました。

仕事場
仕事場 posted by (C)Satohru
0 コメント

2011年4月7日木曜日

次期プロジェクトの要件定義手法

ラベル: , , , , , , , , ,
今度のプロジェクトでは、ひとつの問題領域を2チームで要件定義する予定。そして、チーム毎の作業を対照的に行うことで、成果の品質を高めるという目論見。

下図はサンプルです。

次期プロジェクトの要件定義手法
次期プロジェクトの要件定義手法 posted by (C)Satohru

要件定義手法のRDRA、ユースケース駆動開発手法のICONIXプロセスを組み合わせて、UMLをツールとして使用します。
モデリングツールはEnterprise Architect。9.0が間に合うといいけど…
ちなみに、上図はEnterprise Architect 9.0のベータ版で「手書き風」にしてみました。
4 コメント

2011年3月28日月曜日

Enterprise Architect で手書き風

ラベル: , , ,
ちょっと気分転換に、Enterprise Architect 9.0のベータ版を操作してみました。
ダイアグラムのプロパティとして実装された「手書き風」機能。私はこういう機能、好きです。
かわいいフォントを用意しないと…

Enterprise Architectで手書き風
Enterprise Architectで手書き風 posted by (C)Satohru
0 コメント

2011年2月27日日曜日

簡単なソフトウェアを作ってみよう(2)

ラベル: , , , , , , , , , ,
　前回は完成したソフトウェアをご覧いただきました（例外処理や永続化の実装を除く）ので、今回は設計図書をご覧ください。
　設計≒モデリングには、Enterprise Architect 8.0を使い、工程としては要件定義から、モデルとしてはRDRAに則りコンテキストモデルの作成から進めました（参考：ソフトウェアの開発プロセスについて）。
　今回のプロジェクトは、ソフトウェア開発の世界を知らない人のために、ソフトウェアが生まれるまでを見せようという目的ですので、実際には他のモデル（要求モデル、業務モデル、概念モデル、画面帳票モデル）も作成しましたが、その内、開発の核となるもの≒ICONIXプロセスの成果物を中心に紹介します。
　実際に動作しているソフトウェアを見ながら、下記2図を眺めてみてください。

　本図は、コンテキストモデル、ユースケースモデル、ユースケースシナリオ、ロバストネスモデル、画面モデル、クラスモデルから構成されています。
簡単なソフトウェアを作ってみよう(2)
簡単なソフトウェアを作ってみよう(2) posted by (C)Satohru

　この図はシーケンスモデル。画面とオブジェクトとのやり取りを表しています。

簡単なソフトウェアを作ってみよう(3)
簡単なソフトウェアを作ってみよう(3) posted by (C)Satohru



簡単なソフトウェアを作ってみよう(3)に続く…
0 コメント

2010年10月19日火曜日

ソフトウェアの開発プロセスについて

ラベル: , , , , , , , ,
本コンテンツの趣旨としては、世の中の知恵を集めて自己の基礎を作り、後は状況に応じてカスタマイズしましょう、というようなことです。
先人の知恵として、富士通SDEM、共通フレーム2007、RDRA、ICONIXを取り入れています。




3 コメント

2010年1月17日日曜日

Enterprise Architectでシーケンス図

ラベル: , , , , ,
昨日は、我が社のWebシステム開発案件の見積を出すために、Enterprise Architectを使ってシーケンス図を作成しました。考えてみると、最近は要件開発が多く、ほとんど設計をしていなかったので、まともなシーケンス図をEnterprise Architectで書いたのは初めてかもしれません。

Enterprise Architectを使う前は、Visioを使っていました。今でもVisioは好きなツールのひとつですが、UMLモデリングに関しては、やはり専用ツールであるEnterprise Architectが機能、表現力、生産性の点で圧倒的に優っていると認識しています。
上図は、ロバストネス分析で抽出したバウンダリ、コントロール、エンティティを基に作成したシーケンス図ですが、ストレスなく、よって思考が妨げられることなく、気持ちよくモデリングできました。そして、Enterprise Architectの最も素晴らしい点は、安価であるということです。

関連記事
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA
1 コメント

2009年11月14日土曜日

システム開発の要件定義に関する考察

ラベル: , , , , , , , , ,
私は先日、KenichiroMurata氏のブログ「要件定義の怪物、ビジネスルールをいかにして仕様化するか？」を読みました。これは、システム開発の上流工程に携わる人々にとって、大きなテーマだと思います。

私は富士通グループの開発者と仕事をすることが多いのですが、その富士通にはSDEM（Solution-oriented system Development Engineering Methodology）という優れた開発標準があります。大変残念なことに、SDEMに関する詳細な情報を富士通は一般公開していないので、その内容を詳しくお伝えすることができません。しかし、SDEMは共通フレーム2007との整合性を考慮しているので、基本的な考え方は共通フレーム2007と同質です。
＊一言でいうならば、SDEMは共通フレーム2007をより具体化したものである、といえます。しかし、富士通に確認したところ、SDEMはあくまでも富士通のオリジナルのナレッジであり、他の様々な規格やフレームワークとの整合を図りながら絶えず進化している、というような趣旨の回答を得ました。

この共通フレームにおいて非常に注目すべき点は、要件定義という「何を作るのかを定義する」プロセスが、2007年9月に公表された共通フレーム2007において新設されている点です。また、私自身が要件定義の重要性を再認識し、その方法論を見直したのは今年の春ごろです。要は、比較的最近になって上流工程の再整備が始められたという点です。
これ以前はひと世代前のSDEMの開発工程のように、要件定義は設計工程の一部分として捉えられていたのです。しかし、システム開発にスピードと低コスト、複雑性が増す一方で安定性はより強く求められる。簡単にいってこのような開発パラダイムが支配しだしたとき、要件定義の重要性がクローズアップされてきたのです。そして私も、次期基幹システムで人生最大規模のシステム開発に着手し、自分の方法論の未熟さを痛感することで、やっと要件定義の重要性を再認識できたのです。「知っている」ことと、実体験を伴った「本当の理解」とは、全く違うものだと私は思います。

さて、私はSDEMに影響を受けているので、システム開発の工程を次のように捉えています。
  • システム化の構想と企画(VP,SP)
  • 要件定義(RD)
  • ユーザーインターフェース設計(UI)
  • システム構造設計(SS)
  • 製造工程(PS,PG,PT)
  • 結合テスト(IT)
  • システムテスト(ST)
  • 運用テスト(OT)
  • システム運用保守(OM)
これらの工程のうち、ビジネスルールを固めていくのは、RDとUIのふた行程です。RDでビジネスルールを洗い出し、UIでその詳細を設計するというのが一般論でしょうか。しかし、設計過程でビジネスルールの複雑性が露呈することによって、工数が増えるという問題が発生しがちです。SDEM等では契約を工程毎に分割することでリスクをヘッジすることを提唱していますが、これは根本的な解決にはならず、むしろ開発陣に甘えを与えかねません。また、工程毎にシステム要件や見積りのレベルに合意をとる、というのは論理としてはあるのでしょうが、「先に起こることをあらかじめ知っていること」が最大のリスクコントロールであるとした時、あまり効果があるとは私には思えません。

システム開発の問題の本質は、現実世界からシステム世界への変換過程において、その変換の対象と変換方法を正確に知るのが工程のかなり後にあることです。となると、要件定義において、ビジネスルールを明らかにするべきなのは明らかなのですが、実務上の課題は、どのレベルをもって明らかであるとするかです。
これには試行錯誤と実体験を重ねる時間が必要でしょうが、今時点として次のような条件が考えられます。
  • ビジネスルールのすべてがRDRAの機能モデルとして洗い出されていること。
  • すべてのビジネスルールについて、インプットとアウトプットがRDRAの各モデルと結合する形で洗い出されていること。
  • ビジネスルールをコードに変換する際の問題や課題について、経営層、管理層、実務層といったユーザーと開発陣が議論をし、リスクについて評価できること。
まだまだ研究すべきことがシステム開発にはたくさんあります…

関連記事
簡単なソフトウェアを作ってみよう
性質変換によるデスクワークの工場化
ソフトウェアの開発プロセスについて
Open Knowledge System
流麗な上流工程の研究（メモ）
コンテキストモデル（カスタマイズ版）
流麗なシステム開発の上流工程を実現するために
小さな要件開発
システム開発の要件定義に関する考察
要件開発の進め方～私のRDRA運用法～
RDRA(2) - RDRAとの出会い
RDRA
2 コメント
登録: 投稿 (Atom)