太極拳とUMLモデリングとプログラミングと。
いつもブログをご覧いただきありがとうございます。試験的にアメンバー記事での掲載をしています。
UMLモデリングのコツや心構え・考えかたなど、非常にソフトな面について知りたいかたがどの程度いらっしゃるのか知りたいためです。お手数をおかけしますが、記事を読むためにアメンバー登録をお願いいたします。
  • 18Jun
    • UMLで分析モデリングをするときのポイント

      UMLモデリングで、分析モデリングをするときは、基本的にソフトウェアでの実装意識しません。こういう風に構造を作らないとそもそも実装が難しいとか、あんな風な構造にした方が実装するときに楽になるとかそういった考えを込める事はしません。しかし、人というものは、どうしても心配事が先に立つ。ついつい、実装を意識した思いが浮かび上がって、もし1つ消えても、また思いが浮かび上がってきます。知っておくと良いことがあります。1つ、"実装に都合の良い考え"を取り込むタイミングは、このあとのフェーズにある。2つ、分析途中に思いついた"実装のための不都合もアイディア"も、多くの場合、近視眼的で、開発が進むにつれ不具合の温床になる。分析設計の技術は、それ自体を磨くことも大切ですが、自分の一時的な思いに飲み込まれないように行動できる事が、現実にはとても大切なのです。人としての落ち着きを持って、技術ばかりに目を向けるだけではない技術者でありたいですね。

  • 17Jun
    • 開発におけるUMLモデリングのメリット

      今日、開発におけるUMLモデリングのメリットは何か聞かれたので、とりあえずいろいろ挙げてみる。・要求や設計を自然言語よりも緻密に整理でき、より早い段階で、要求や設計上の不足や不整合といった類の不具合を発見し修正できる・要求や設計の整理を、より緻密さを持って、他人と話し合うことができる・要求や設計を、自分自身で客観視して、俯瞰的に精査できる・要求分析と設計とを分離しやすく、関心事ごとに課題を解決しながら進ませ易いため、混乱や手戻りを防止しやすい。・UMLモデリングしてから実装したら、ビルド後にすぐに動くか、一つ二つの修正で動くようになる・不具合収束するまでの開発期間が、三分の一以下になったりする・複数の外注に実装を出していても、それぞれの分担範囲が明確で分かりやすいあと、何を話したか、忘れてしまった(´༎ຶོρ༎ຶོ`)

    • 開発におけるUMLモデリングのデメリット

      今日、UMLモデリングのデメリットを挙げてほしいと頼まれたので、色々と挙げてみた。もちろんこれ以外にもあるとは思うが。・UML表記法の学習コストがかかる・UMLモデリングの学習コストがかかる・モデリングツールの費用がかかる・モデリングツールの学習コストがかかる・UMLモデリングをするよりも実装を急がせる圧力が開発メンバーにかかる・UMLモデリングだけを導入すればいいのかと思えば、モデルと実装コードの変換ルールの策定も必要になる

  • 11Jun
    • クラスの属性にあったら変なもの

      クラスの属性に、そのクラスがどんなものであるかを示すフラグや状態変数があったら、おかしい。だって、これはこういうもんだよってことを示すのがクラスなんだから。例えば、動物クラスに、フラグ bool is猫 や、動物種別という属性があって、いちいちそのフラグや種別を見て、switch文やif文を書いていたら、それはいいプログラミング?

  • 09Jun
    • 抽象と具象を行き来の勉強法

      皆さんは、モデルベース思考というのをご存知だろうか?抽象と具象を行き来することを、丹念に教えてくれるものです。できる人には当たり前、でもできない人には目が開かれる思い。でも、できる人から見ても、こうやって教えれば、ずいぶん分かって貰いやすいんだな、と感じるところがたくさんあります。https://www.amazon.co.jp/dp/4799318721

  • 08Jun
    • オブジェクト指向言語だから、継承を使わなきゃいけないわけじゃないよ

      今のプログラミングをする人は、ほぼみんな、継承があるプログラミング言語を使っていますよね。もちろん、C言語を使ってる人もそれ相当にはいると思いますが、今回は、継承がある言語を使っている人向け。多くの人は、継承って、使って当たり前って思っていませんか?でも、継承っていうのは、クラスとクラスを密に結合させる仕組みなので、変更の影響が見えないところに及んだり、不具合修正の確認範囲が見通せなくなったりします。継承の使い所がきちんとわかっている人にとっては、とても良い道具だと思います。しかし、プログラマの大半の人には、かなり難しい技術だともいえます。ある大規模プロジェクトでは、継承の利用を禁止していると、聞きました。多少の利便性よりも、開発の混乱を避けることを優先させたということです。当たり前だから使うのではなくて、どの程度使うことが自分たちにとって適切なのか、トレードオフはどうなのか、それを知った上で、継承を使うことをお勧めします。

  • 05Jun
    • ”自然物とモデリング”

      みんなの回答を見る目に入った花を、瞬時にモデリングしている。今でもそうだけれど、日常的に見たものを瞬時にモデリングする癖がある。一種の職業病だ。でも、仕事ですらすらモデリングするには、このくらいの自然な慣れが必要だと思う。初めてモデリングを本格的に学び始めた時、上司に言われた事は、通勤中に見たもの何でもいいからモデルにしてみなさいと…。はじめは結構大変だったけれど、気張りすぎていたから大変だったのもあったと思う。今はそこまで気張らずに、軽いイメージのモデリングをしてると思う。プログラマの人、こんなことしても何になるのかわからないかもしれないけど、わかりやすいモジュール分割をするにはこれが1番便利。はじめは、試行錯誤でもいいから、とにかくやってみてほしい。きちんと疑問にぶつかるようになったら、誰か教えてくれる人や本に出会うから。

  • 04Jun
    • 頭をクリアにして思考力を上げるためには

      頭のいい人って、頭の中に思考やいろいろな知識が、いつも、たくさんあるような気がしてしまいますね。私は決して非常に頭の良い人間ではないけれど、最近、殊に思うことがあります。それは、頭が明晰になるときは、思考を停止しているときだということです。だいぶ昔ですがGTDと言う本が流行りましたね。頭の中にあるタスクを紙に書き出してしまって、頭をスッキリさせることで、いますべきことに集中させます。いま考えると、同じことかなって思いました。思考力の強い人は、多すぎる思考を停止させて、スッキリして、集中して向かい合うのかな。

  • 01Jun
    • スマホのメールのバッジを非表示にしてみたら、、、

      スマホのホーム画面のアイコンに出てくる数字がありますよね。メールアプリだったら、新着メールの件数が出てますね。あれは、バッジというそうです。スマホの画面を見るたびに、あの数字が出ていると、ついついメールアプリを立ち上げてしまいます。いつもいつもメールが気になってしまって、つい開いてしまいます。なんか、心が落ち着かないのです。だいぶ前になりますが、ソフトウェアのコンサルタントで有名なトムデマルコの本(だと思うのですが)で、人間の想像力や生産性を落とした要因の一つは、電話の発明だと書いてありました。他にも交通の発達が人間の創造性を落としたとも書いてあったと思います。昔は、馬車に揺られながら長い時間考えることができた。電話が鳴って突然呼び出されることもないから、邪魔されずに取り組むことができた。私自身は、電話の文化からEメールになって、メールは自分が読みたい時に読めばよかったので、意外と良くなった感じはあったのですが、スマホを使うようになってから、またメールに追われるような感じになりました。つまり、スマホのホーム画面に出てくる表示が、電話でいうところのベルが鳴っているところなんですね。数週間前から、このバッジ通知をオフにしました。自分で見ようと思った時しか、メーラーを開きません。すると、以前に比べてずいぶん日常の気分が楽になるようになりました。皆さんも、いちど試してみてはいかがでしょうか。

    • ビジネスモデル2.0図鑑

      ビジネスモデル2.0図鑑という本を買った。ちょっと古いらしい(書店員さん曰く)この本の中を読んでちょっといいこと書いてあった。3ページ目本書に掲載されている100個の事例も、永遠に「すごいビジネスモデル」であり続けるわけではない。私は、コンサルティングするときに、フレームワークを自作すべき人には、開発対象システムの本質の姿を捉えてもらっている。もちろん本質とは何かといった話を、具体的な開発対象に合わせて話し合っているので、本質を捉えさせること自体は、それほど難しくは無い。つまり、フレームワークを作るときは、本質を見抜く抽象化を行っている。ビジネスモデル2.0図鑑は、題材となっているビジネスの本質をモデル化している。つまり、本質を見抜く抽象化を行っている。両方とも同じ対象の本質を見抜く抽象化を行っている。ここで言いたい事は「本質」といっても、それは永遠に通用するわけではないということです。ソフトウェアのフレームワークでは、機能の変化や新しい部品への拡張に通用する本質を抽出しなければ、フレームワークとして通用しません。しかし、ビジネスモデル2.0図鑑でいうのと同様に、永遠に通用するわけでは無いのです。ですから、変化は必ずある、フレームワーク自体も変化はする、でも、そのソフトウェアが生き残るだけの間、変化が少ないような本質を抽出するという、加減が大事なのです。フレームワークを作るためには、モデリングで抽象化を行います。この抽象化をするときに、今述べた加減があるのです。

  • 31May
  • 27May
    • 認識の大切さ

      今日、TOCクラブから来たメールに書いてあったゴールドラット博士の言葉。人の脳力には、なんの問題もない。人が現実をどう認識するかに大きな間違いがあるのだ。オブジェクト指向分析でモデリングするときもどう認識して描いたかで、システムの良し悪しが決まる。この認識する力、見抜く力を掴むことが大切。でも、それをマニュアル的に教育する方法は、今のところない。あるとしたら、TOCの中か。普通は、出来る人との間で、身につけるだけ。テクニックだけじゃなくて、心を鎮めることとかもあるし。

  • 26May
  • 16May
    • 教育、腑に落ちた言葉

      腑に落ちる言葉に会った教えの本質とは、体験そのものを与えることではなく、体験までの準備をさせることにある。

  • 14May
    • ”形だけやってもダメよ”

      みんなの回答を見る1年前に、太極拳もソフトウェア開発も、形だけじゃなくて中身は何を意味しているのかを持っていなければならないと記事を書きました。それに絡んだ話ですが、太極拳の練習は主に套路と呼ばれる型の練習をします。これは戦いの流れを形にして練習するものなのですが、これをシミレーションさながらに練り上げることで、その後、様々な戦いの流れに使えるようにします。ソフトウェア開発の訓練と言えば、このような型のをやったとしても、1回やって、後は実践がほとんどだと思います。これでは中身を十分に養うことが難しいです。ソフトウェア開発の訓練でも、太極拳のような考え方で訓練方法構築しても良いのではないでしょうか。

  • 13May
    • 自分の心の奥底に聞こえるものと心の中に聞こえてくる言葉の声

      1994年に読んだ漫画「セイバーキャッツ」に、主人公のお父さんの言葉として次の言葉が書かれています。魂は、嘘をつかない。その日その時その場所で心は姿を変えようと決して魂は嘘をつかない。それから20年ほど経ち、時々、人に本当に思ってることを話してもらおうとしても、本当に心の底から思っていることと、そうではないことと区別がついていないなぁと思う経験がありました。私自身も、心の底から感じていることとそうでないことの区別をどう説明したらいいのかずっとわかっていませんでした。心の底から感じていることとは、意識とは関係のない、言葉とも関係のない、自分の中を静かにしたときに聞こえてくるもの。そうでないこととは、自分の心の中に聞こえる言葉になってくる声のこと。心の底の声を聞こえなくするもの。実際には、自分の本当の声にかかわらず記憶が作り出してしまう声。多くの人は、この心の底の声の方なかなか聞き取れないのだと思う。もしくは、聞き取れたとしても、そうでない心の中に聞こえる言葉の声と区別できなくなっているんだと思う。仕事上、「本当にそう思ってるのか?」を聞いてみることが何度かあったけれど、明らかに、この2つを取り違えて、記憶が作った雑音の方を、自分の本心と捉えていると思われる人たちがいました。でもそれ以上うまく聞き出すことができなかった苦い経験が残りました。話を戻すと、昔読んだ漫画に書かれていた、「魂」は心の奥の底で聞こえる言葉ではないが聞こえてくるもので、「心」は自分の心の中に言葉として聞こえてくる声なのだと、今になって理解してきたみたいです。この2つの違いを、やっと自分で説明できるような位に整理ついてきたんだなぁ(^^)と、思っただけの話でした。

  • 08May
    • 今日はゴーヤーの日

      ゴーヤー、食べれる?▼本日限定!ブログスタンプあなたもスタンプをGETしようゴーヤといえば、ゴーヤチャンプルーですね。いま、スーパーにも出ていました。さて、ゴーヤをUMLで描いたらどうなるのでしょうか。一般論として、こういう特徴を持ったものが、ゴーヤである。をクラス図にしたら、どうなりますか?イボがたくさんある緑色、ただし、熟れると赤い種があるわたがある苦味があるあー、熟れる話を入れると、ステートマシン図があると良いですね。誰か、リブログして、描いてくれないかな。