Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。編集部ブラジルの国民医療システムは、2百万行を越すコードと350クラスのドメインモデルを有しており、今までに構築された最も大きなエンタープライズJavaアプリケーションだと言われています。アプリケーションは、全国規模の医療システムとして考えられるすべてのドメインコンセプトをモデル化しています。ブラジルの人々のためばかりでなく、公共の医療システムのためにも、非常に大きな価値を創出するほどの水準の自動化をもたらしています。この種のケースでは唯一である本ケーススタディでは、アーキテクチャ、興味深いソリューション、学んだ教訓、プロジェクトの将来の方向性について、その詳細に目を向けます。問題領域ブラジルは完全に無料の公共医療システムを持つ世界中で数少ない国のうちの1つです。このような規模のあらゆる公益事業と同様に、多くの運用上の問題がありました。システムの大部分は紙ベースであり、既存のITシステムおよび国や地域の医療機関の間で、システムはほとんど統合されていませんでした。医療機関がお互いに患者の予約を入れることのできるスケジュール管理システムがありませんでした。心臓の専門医を訪れなければならない患者は、空いている専門医を自分自身で探す必要がありましたが、そのためには、十分に早い空きを見つけるまで何人もの専門医の長い列に並び、複数の予約を取るという方法がよく使われました。手術歴、治療中のあらゆる時点における病状などの、患者の病歴についての情報がありませんでした。診断などの重要な統計データが、統合されていない紙ベースのシステムに保存されていたため、政府は医療資源の容量の計画や不足への対処ができませんでした。医療法規や方針をモデル化したITシステムが治療管理システムに統合されていなかったため、医療システムの不正使用の検出や防止を行えませんでした。地方の医者の多くが情報システムを全く持っておらず、スケジュールが管理されていなかったため、患者は一日中待たなければなりませんでした。Saudeと呼ばれる医療自動化システムの構築が発注されました。機密アクセス管理などの、公共の医療情報システムとして考えられるすべての面を処理するように設計されています。関連スポンサーコンテンツシステムは最初にサンパウロ市のすべての医療ユニットを自動化するために配備されました。サンパウロ市はブラジルで最大の都市で、世界では第4位、2千万人を超える人口を有しています。今日では、アプリケーションはサンパウロと他の20の都市で稼動しています。ブラジルの他の都市だけではなく、ポルトガル語を公用語とするアンゴラやモザンビークなど、自国の医療システムの自動化にも興味を持つ他の国にまでシステムは拡張しつつあります。Strutsをベースにして、データ転送オブジェクト、セッションファサード、サービスロケータ、そしてビジネスデリゲートなど、確立されたEJBデザインパターンを使用して、明確に定義された階層アーキテクチャを活用しています。開発はEclipseで行われ、テストとデプロイはJBossアプリケーションサーバで実行されました。3.1サーバにデプロイされています。3.2.7が動作しています。構想から要件や開発まで、医者や医療の専門家を含む150人を超える人々が携わり、システムはどうあるべきかを明確にしました。開発チームはシステムを次のようなモジュールに分類しました。上記のモジュールのコード数は、サービス層と、このようなモジュール特有のドメインモデルに含まれる行数です。10万行のコードがサービス層のモジュールで共有され、また57万行のコードがドメインモデルで共有されています。本当のコード数は気が遠くなるような数かもしれませんが、後ほど記述するアノテーションの使用についてのドリルダウンにあるように、実際はコード数のうち58%は生成されたコードです。上記のビジネスモデルはそれぞれJSPページ、Strutsアクション、そしてビジネスデリゲートから成っており、サービス層を呼び出します。2.1のセッションビーンから成ります。ドメインモデルは、エンティティビーンを作成するのに使われるアノテーション付きのPOJOで構成されます。次のドリルダウンでは、スケジュール管理システムを、urlからsqlまで詳細に渡って説明します。このモジュールの全体的な階層構造は他と同じであり、システムがどのように構築されているか深く理解できるにちがいありません。ドリルダウン:専門医の予約のスケジュール管理を行うユースケースこのシステムにおいて、ビジネスと技術の両方の見地から最も重要なユースケースの1つは、地方の小さな診療所の受付係が患者のために専門医の診察の予約を取れる、というケースです。このユースケースはスケジュール管理モジュールで実装されましたが、システムの他の多くのモジュールにも影響を与えています。スケジュールの予約というユースケースは次のようになっています。受付係はスケジュールの中に空いている時間枠を探そうとします。種類、特定の医療処置などによる問い合わせを発信することができます(ここ(JPG・英語)をクリックすると入力画面を参照できます)。下のシーケンス図にある“getSlots”を見てください。他の連絡先情報を調べることによって(searchPatient()を参照)、患者のプロフィールを探します。それから同じ画面上で必要な処置の種類を入力します(2番目の入力画面参照(JPG・英語)、シーケンス図のsaveAppointment()参照)。空きがないとか、診療所がそのような処置を行っていない、という理由で、その診療所では患者が必要な処置が受けられない場合は、受付係または医者が他の診療所の空き時間を探せます。このシーケンス図は、典型的なユースケースがシステムでどのように実行されるのかを示しています。Strutsのアクションクラス(ScheduleAction)がユーザーの要求を処理し、プレゼンテーション・ロジックに対応します。データの取り込みやビジネスルールの呼び出しが必要な場合、アクションクラスは、ビジネスデリゲート・デザインパターン(ScheduleCF)を実装したPOJOオブジェクトのメソッドを呼び出します。このクラスは自動的にセッションファサード・クラス(ScheduleSF)から作成され、サービス層に使われている技術にウェブ層が依存しないようにしています。セッションファサード・デザインパターン(ScheduleSF)を実装したセッションビーンは、ビジネスルールの実行を他のクラスに委ねます。AppointmentServiceクラスは、lockSlot()メソッドとsearchForSlot()メソッドを実行します。ユースケースがデータを保持する必要があるときは、setAppointmentVO()メソッドがエンティティビーン上で呼び出されます。検索は、エンティティビーンの仕組みを使うのではなく、Searcherと呼ばれる最適化された検索コンポーネントを使って行います。セッションファサード・オブジェクトは、トランザクション・サービス、データベース接続、および他のアプリケーションへのセキュリティ・サービスの提供を担当しています。サービス・オブジェクトはPOJOであり、エンティティビーンに直接Web層からアクセスすることができないので、セッションビーン層が必要とされました。時間枠がロックされると、タイムスタンプとロックIDが時間枠データベース・テーブルに保存されます。UPDATEコマンドで保存されます。タイムスタンプは、ロックが時間切れになったかどうかを判別するために使われます。ロックIDは、オブジェクトが時間切れになったロックを保存しようとする状況を避けるために使われます。ロックを要求したオブジェクトが予約を保存することに決めると、受け取ったロックIDとテーブルに保存されたロックIDを比較します。それらが異なる場合、新しい情報は保存できません。このように、ロックの要求と予約の保存の間にロックが時間切れになった場合は、アプリケーションはこれを検出してユーザに通知します。このユースケースは論理ロックを実装しています。データベースロックやEJBロックは長い時間保持されないので、ビジネスルールの方がうまく実装できます。.このユースケースに関与したドメインオブジェクトの(簡素化した)クラス図を以下に示します。コード生成はこのプロジェクトの主要な戦略でした。プロジェクトの開発期間が短く、開発者の生産性を上げ、バグの数を減らす技術が必要だったためです。そこで、XDocletの元々のテンプレートは”専門家のコード“を生成するように変更されました。XDocletのアプローチは、プロジェクト開始後10ヶ月はうまくいき、開発者が必要とする生産性を上げる助けとなりました。それからしばらくして、コードが増加するにつれて生成時間もまた増加し、それによって生産性が深刻な影響を受けるに至りました。アノテーションを使用してコード生成を行う戦略に変更することに決めました。アノテーションを使用する戦略によって、いくつかのXDocletの難点を解決することができました。配置記述ファイルのようなファイルの増加分の生成が可能になりました。XDocletは、1つのクラスが変更されるとすべてのクラスを再び読み込んで、新しい配置記述ファイルを生成します。アノテーションを使用することで、クラスの変更によって影響を受けた配置記述ファイルの一部分だけを生成することができます。開発者がほんの少しのクラスしか変更しない場合がほとんどなので、これによって多くの時間の節約になります。1は、生成時にサブコンポーネントのソースコードにアクセスする必要があり、それが結合や構築の複雑さを増加させていました。コンパイルされたjarだけにアクセスすればよい、というのが望ましいのですが、すべての開発者はすべてのソースコードにアクセスしなければなりませんでした。アノテーションを使うことで、この問題を回避できました。実行時にアノテーションを処理することができるので、コードを生成するかわりに、この機能を使うことでうまくいくこともあります。3.0アノテーション用の処理装置と、他にXDocletが生成するのとよく似たコードを生成するような、カスタムメイドのアノテーション用処理装置を開発しました。2.1に対応していました。アノテーション用処理装置のテンプレートとしてVelocityテンプレートが使われました。1と同じくらい幅広く、テンプレートとヘルパークラスのセットを作り上げることでした。アノテーションを使うことによって、生成時間はかなり減少しました。1つのクラスが変更された場合、XDocketを使うと400クラスからコードを生成するのに1分50秒かかっていました。APTだと同じ処理が10秒で終わりました。ドリルダウン:ルールエンジンがビジネスロジックを単純化した方法システムの一部分ではビジネスルールを扱う必要がありましたが、それは都市や政府法案によって異なり、また時間の経過とともに変わります。診療所がX線を使った処置を行おうとしたら、X線装置を有することや、公認されたX線技師がいることなどのいくつかの規則に従わなければなりません。このような規則はしばしば変更されるので、これらはコードの外に置く方が無難です。すれば、コードを変更することなく規則を変更できます。Saudeでは、javaのルールエンジンAPIでJSR-94の実装であるDrools(サイト・英語)ルールエンジンを使ってこの問題を解決しました。Saudeのコンポーネントによって行われます。このコンポーネントはルールセットと作業メモリを使います。ルールセットは一連のメッセージを使いますが、その際に各ルールは1つのメッセージを持ち、それはbr.com.vidatis.common.decision.message.RuleMessageインターフェースを実装するクラスによって記述されます。1つのルールもしくはルールのサブセットが満たされると、関連したメッセージは待ち行列から削除されます。このように、ルール処理を追跡することができます。最後に待ち行列にメッセージがなくなると、ルールはすべて満たされます。ルールは、新しいルールセットを含む、いくつかの異なるアクションを起動することができます。これらのルールはXMLファイル内に記述され、Droolsエンジンによって処理されます。</java:consequence></rule>これは、診療所に関するデータを保存しようとする例です。サービスクラスがDroolsルールエンジンを呼び出して、認証規則の適用を要求しようとしています。すべての規則に合格するとデータは無事に保存されます。このような認証規則は政府による法規制の変更に伴って変わります。規則は頻繁に変更されるので、コードから認証規則から分離することは重要です。そのようにすることで、アプリケーションを再起動せずに保守作業を行えます。学んだ教訓コード生成はこのプロジェクトの主要な成功要因でした。それによって開発者の生産性が向上し、コードが均一になりました。50人もの開発者が全員同じ基本コンポーネントを共有しながら、それぞれ独立したチームで働いているような場合に、均一なコードを持つということは非常に重要です。XDocletを使いましたが、しばらくすると、生成時間が非常に長くなるという好ましからざる副作用を生じました。アノテーションに変えることで、生成時間を減らしながらもコード生成の恩恵に与ることができました。意思の疎通が良好であることは不可欠です。今回のような巨大なプロジェクトには、時おり違う言葉を話しているのではないかと思えるような様々な“種族”がいます。彼らにお互いの考え方を理解してもらうのは難しく、またイライラすることもある作業です。このような種族間の意思疎通はなかなか厄介です。私たちは自分のたちの出来る仕事をすべきです。アーキテクトが積極的に開発活動に参加すると、より良いソリューションを提案し、生産性を上げることができます。これがチームの“幸福度”を上げるのに役立ち、それがまた生産性に影響を与えます。両者の意思疎通がうまくいかないことが、遅れや不満の原因になることがよくあります。できた仕様は必須ですが、よいユースケースの仕様だけでは、双方のグループの動機を理解し、チームとして行動させることはできません。プロジェクトには、各メンバがソフトウェアを作る素晴らしいアイディアが詰まった頭脳を持つ、並外れた開発者チームがありました。開発期間が短かったため、日々彼らの頭に浮かぶ革新的なアイディアをすべて試すのは不可能でした。このことが、チームに欲求不満をもたらしました。このようなプロジェクトでは、明確な目標を保ち続け、なぜこのような決定が成されたのかを全員に理解してもらうことが重要です。この点で助けになったのは、チームが定期的に数週間のリファクタリングを行ったことです。その数週間の間に、チームは問題について、またそれを解決するために何が変えられるかについて議論し、その間にシステムのリファクタリングを行いました。新しいコードを開発することなく、コードを修正するためだけのリファクタリング専用の1週間は、新しいアイディアを利用し、生産性を向上する助けとなります。ルール、コード生成、デザインパターン、コンポーネントが存在する、明確に定義されたアーキテクチャなら、小規模または中規模のソフトウェアのリファクタリングを行うことは簡単です。大規模のリファクタリングはいつも大変です。厳しい規則もアーキテクチャがあまりよく適用されていないアプリケーションの20%の実装を困難にします。アーキテクチャの標準化の実施に関して、どこまでやるべきか理解することは重要です。プロジェクトの最中に、開発者がアーキテクチャにソリューションを適用しましたが、それが最も効果的な方法ではない場合もありました。その一方で、ユーザーインターフェースのように、システムの中で規則があまり厳しくない部分では、開発者が各自でソリューションを選択したために、システムの一部の品質が低下し、コードの保守が複雑になるなど、望ましくない結果を生じました。巨大なアプリケーションにおいて、依存関係やコードが多い場合は開発サイクルが長くなりがちです。時には、簡単なフィールドを1つ画面に追加することがシステムの多くの部分を変更することになり、時間がかかってしまいます。これは開発者と顧客の双方にとってイライラさせられることです。ツールがとても重くなり、すべてが本来の時間より長くかかるように思えます。アプリケーションをいくつかのコンポーネントに分割しましたが、問題を完全に解決するには十分ではありませんでした。J2EEにはメリットがありますが、コードがさらに複雑になるという点もあり、これは生産性の面では高くつき、経営者や顧客に説明するのに骨の折れるところです。チームがこのプロジェクトを開始した頃、こんな開発期間で行うのは無理だと多くの人々に言われました。他の国々では、公共の医療情報システムを構築する際に苦い出来事が数多く経験されてきました。この経験から学ぶ最後の教訓はこうです。「人が無理だと言ったとき、その通りにしたら成し遂げることはできません。将来の方向性コンテナの外からのテストの実現コンテナの外からテストができないことはチームを本当に煩わせています。当初それができなかったのは、旧式のコードから始めざるを得なかったからです。1.0のシステムでした。すべてのエンティティビーンおよびコンテナの他の加工品はコード生成を使用して作成され、アプリケーションの新しい部分は次第にPOJOベースになってきています。コンテナにデプロイすることは、変更した部分だけですら、開発者たちが喜んで受け入れることが出来ないほど時間がかかっています。現在のシステムには明らかに多くのコンテナ依存とEJB配管コードが存在します(生成されたビジネスデリゲートおよびセッションファサードによってほとんど隠されていますが)。移行しようとしているのは、ビジネスルールを含む、完全にPOJOベースのアーキテクチャです。チームは、すべてのセッションビーンを1つの単一のビーン・インターセプターにリファクタリングしたいと考えています。することで呼び出しはサービス層に委ねられます。セッションビーン・インターセプタの目的は、トランザクションおよびスレッド管理などのミドルウェアサービスの提供を簡単にすることです。Springを利用しようと考えていましたが、既存のアーキテクチャを変更することをかんがみると、費用がかかると考えられました。既存のセッションビーンはすべて生成されたものなので、EJBから完全に消してしまうのではなく、セッションビーン・インターセプターを通るようにコード生成ロジックを変更すればよく、非常に簡単です。このようにリファクタリングを可能にしてくれるもう1つの要素として、このような膨大な変更をウェブ層から隠すビジネスデリゲート層の存在があります。その理由は、システムにアクセスする必要がある保健省の他のグループに、ゆくゆくはアプリケーションを公開できるようにする必要があるからです。チームはすぐに使えるビジネスデリゲートを、(サンパウロから来る)人々に手渡すだけですむように考えています。ビジネスデリゲートは遠隔処理のすべての面を隠すので、ネットワーク・パートナーは次第にJavaから手を引いていくだろうとわかっていますが、統合は全く面倒なく行われると考えられます。異なるトランザクションタイプの区別を、どのようにして明らかにするのでしょうか?異なるトランザクションの区分別に異なるメソッドを持たせ、ターゲットメソッドにトランザクションタイプをマッピングしようとしていますので、どれが実行すべきメソッドを呼び出すのかがわかります。Marinescu氏のEJBデザインパターンという本に載っています。:)結局は、おそらく直接Hibernateを使用して値オブジェクトを保持するだけにして、ゆくゆくはエンティティビーンを終わりにしたいと思っています。将来このように変更する際に直面する事のうち、最も高くつくのはテストです。徹底したテストを行わなければなりませんし、単なる単体テストではすべてを網羅できないでしょう。ウェブのUIを簡単にするAJAXAJAXは、技術者ではないエンドユーザーのためのUIワークフローを簡単にするためのツールとして見なされました。スケジュール管理ユースケースで、医者の名前、治療の名前、専門分野の名前などを入力する際に、オートコンプリートはその助けとなることができました。ポップアップの呼び出しや検索を行うことなく、大きなリストの中から選択すればいいのです。長くて大きいフォームを使って作業するときは、間違えてクリックしてページを消したり、作業内容を失ってしまったりすることのないように、1つずつHTTPSessionに送られる画面のフィールドの値を保持してくれるAJAXを使う方が賢明です。AJAXは最近すでにデプロイされました。AJAXは階層化された膨大な手続きをナビゲートし、その一方で、必要であれば要素を検索するのに使われています。これによってより良いインターフェースをユーザに提供できるようになり、データの入力時間が減少しました。ここ(JPG・英語)をクリックすると画面例を参照できます。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員��して、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。