Think Framework

314 Views

March 31, 24

スライド概要

[第3回大阪sas勉強会]三木 悠吾

profile-image

SAS言語を中心として,解析業務担当者・プログラマなのコミュニティを活性化したいです

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

Think Framework 2018/06/22 SAS Osaka Meeting 2018 June Yugo Miki

2.

Framework • • • ビジネス・フレームワーク • 経営戦略や業務改善、問題解決などに役立つ分析ツールや思考の枠組み。 • ロジカルシンキング、発想法など。SWOT分析、ファイブフォース分析が代表例。 • 適切で客観的な判断をサポートするのが目的。 ソフトウェア・フレームワーク • ソフトウェア開発のためのシステム環境。 • ソフトウェア開発を容易にすることが目的。 本稿はSASのフレームワークについて考察する。

3.

Library vs Framework Library • マクロライブラリなどが有名。 • ライブラリからマクロやプログラムを参照 してプログラム中に利用する。 • プログラムの再利用に特化した使い方。 • プログラミングコードを部品化し、組み 合わせる事でプログラムを作成する。 Framework • SAS LSAFなどが有名。一方、「そ れって一体何なの?」ってくらい実体が 見えない。 • 一般的な機能を持つ共通コードを持 つ。 • 標準的なコードはフレームワークが持ち、 要求されるコードの実現にプログラマー のリソースを集中させる事で効率化を 達成する。

4.

だからどういうことなのさ? • つまり、 • いつも書くコードはフレームワークに持たせましょう! • いつも使う機能はフレームワークに持たせましょう! • よく使うマクロとかもフレームワークに持たせましょう! • ついでに社内ルールとかもフレームワークに持たせておきましょう! ってことです。 • これをSASで良い感じに実現して、快適な開発環境を作りましょう!

5.

SAS programの要素 SDTM to ADaM ADaM to TFLs • Clear log and data. • Clear log and data. • Setting macros. • Setting macros. • Setting library. • Setting library. • Setting format. • Setting format. • Import data and files. • Import data and files. • Merge. • Merge. • Mapping to new variables. • Call procedures. • Sort. • Sort. • Drop extra variables. • Make up to requests from mockup. • Upload. • Upload. • Header, sections, and comments. • Header, section, and comments.

6.

Framework化検討 SDTM to ADaM 考察 • Clear log and data. ⇨ 毎回使う。対象とする。 • Setting macros. ⇨ 毎回使うところだけ対象とする。 • Setting library. ⇨ 毎回違う。出来るだけ一箇所に集約したい。 • Setting format. ⇨ 仕様書のコードリストにあるものは対象とする。 • Import data and files. ⇨ ファイル名と仕様が毎回違う。やや無理。 • Merge. ⇨ 毎回違う。対象外。 • Mapping to new variables. ⇨ 毎回違う。対象外。 • Sort. ⇨ マクロ化してライブラリへ。 • Drop extra variables. ⇨ 仕様書から自動取得。 • Upload. ⇨ マクロ化してライブラリへ。 • Header, sections, and comments. ⇨ SOPや手順との兼ね合い。対象とする。 プログラマーに頑張って 欲しい所はここ! ということはそれ以外の所は フレームワークに持たせた方 がいいよね!

7.

SASによるフレームワーク • SASプログラム開発時を想定。 • SASによるプログラムテンプレート作成の一歩先。 URS • 使用するのはBase SASと一般的な外部ファイル(EXCEL)。 • プログラムからプログラムをcallしても良い。 • 本番実行時のみログを外部に保管。 • マクロは今回はmacro.sasを毎回includeする。 • フレームワーク化検討のほぼ全てを実装する。

8.

SASによるフレームワーク仕様 • 全実行プログラム • • • 全実行時ログを保管。 Macro.sas • Sort。 • インポート(proc sort)。 • エクスポート(proc sort)。 • 仕様書から変数のatttribute作成。 • 仕様書からcodelistのformat作成。 • 仕様書からkeepする変数リスト作成。 Each_dsn.sas Stand aloneで動く。 • 実施時にログ、データセット等をクリアする。 • 社内規則に従ったheader, section, commentを作成する。 • 何だ、いつものやつじゃん。。。 プログラムにおける面倒な“いつもの”を持たせておくのがフレームワークです。

9.

全実行プログラム %macro derive(dsn, title); 基本的にはマクロで実装 proc printto log = “&path.¥&project._&dsn._log.txt” new; title1 ”&project.:&title.”; run; Printto でincludeを挟むだけで開発環境と本番 実行環境を分離できる! %include “&pgpath.¥&dsn..sas”; proc printto ; run; %mend; %derive(adsl) %derive(adae) 開発時:それぞれのプログラムで実行。ログは ログ画面へ出力される。 本番実行時:ログはprinttoで指定したフォルダ へ出力される。

10.

マクロプログラム %macro derive(lib, dsn, key, where); proc sort data = &lib..&dsn out = work.&dsn; by &key.; &where.; run; %mend; Macroはlibraryにして保管・管理しておくと楽 です。今回のmacro.sasはそれ自体がマクロ ライブラリとして機能します。 フレームワークからライブラリが読み込まれる ような仕様にしています。

11.

個別のプログラム① ログクリアが先か?Headerが先か? ・ 常識的に考えるとheaderが先である。だって”head”erだから。 ・ でも少し考えてみてもいい。 dm ”log; clear;”; /* program name : test */ /* author : anonymous */ /* program name : test */ /* author : anonymous */ dm ”log; clear;”; ・ どっちも同じ? ・ でも少し考えてみてもいい。もし、prinnttoではなくdmステートメントでログを保存 していたら?後者の場合、ログからheaderが消えてしまう。どうやってログを残すかに よって使えないパターンがあるので注意しよう。

12.

個別のプログラム② よく見たら進捗管理ファイル、帳票一覧、 ADaM仕様書にほとんどの情報が入っている。 • PhuSE GPPの参考から持ってきました。立派なヘッダーです。 • これを作るの時間かかるんじゃない? → こういうものはフレームワークに持たせましょう。 ちょっと工夫すると結構作れちゃったりするものです。

13.

個別のプログラム③ マクロはいつもどうやって使う? %include statement. 1. • %include ”macro.sas”; Set auto compiled macro. 2. • FILENAME fileref 'the path to the AUTOCALL library’; OPTIONS MAUTOSOURCE SASAUTOS=(SASAUTOS fileref); 3. Set stored macro. LIBNAME mylib 'C:\temp’; OPTIONS MSTORED SASMSTORE=mylib; ・ こんなの開発フレームワークの一環ですよね。どんなパターンでも簡単に実装できる。

14.

個別のプログラム④ マクロをcallしましょう 1. %config 2. %make_blank_dataset(&dsn.) 3. %import(analysis, adsl, usubjid, where SAFFL = ‘Y’) ・ こんな感じでつらつらと記載。 1. libnameなどの設定を一括で。色々クリアする処理を入れる人もいる。 2. ADaMといったらこれ。個別のattribとか狂気の沙汰としか思えない。 3. 毎回使うわけではない。ただ、あると書き方を覚えなくても良い。(exampleとし て載せている)

15.

個別のプログラム⑤ Sectionを設定しよう 1. /* --- general setting --- */ 2. /* --- macro preparation --- */ 3. /* --- data preparation --- */ • こっちもこんな感じでつらつらと記載。 • どういう作りにするかは社内で共通化すれば良い。

16.

生成してみよう Call execute + metadata dataset data _null_; set metadata; call execute(‘%generate(‘ || catx(‘,’, parameter1, parameter2,,,,)|| ‘)’); run; • 定番のcall executeとデータセットの合わせ技。 • %generateはput statementでsas programをひたすら作ってくれるマクロ。

17.

こんな感じ

18.

考察してみた 良かった点 • Headerの記入箇所が少なくて楽。 • 毎回やってた設定が不要になり、ミスもなくなった。 • 余計な設定や処理に悩まされないので、データを見る時間などに作業時間を使えている 気がする。 良くなかった点 • 簡単なプログラムのはずなんだけどやたらとコードが長い。 • 少しプログラムの構造が変わると、適用できない。 • 開発計画が大きく変わると対応できない。

19.

会社としては • やってみてもいいんじゃないの? • 申請や海外に提供するなど、プログラムへの要求が高くなればなるほど威力が出る。 • 会社として基本的なプログラムの書き方やセクションわけなどを決めてしまっても、この 方法ならコスト高にならない。むしろ、いつもここにこういう事が書かれていると分かっ た方が開発、またはそのための教育においても有利。

20.

夢なき者に理想なし、 理想なき者に計画なし、 計画なき者に実行なし、 実行なき者に成功なし。 故に、夢なき者に成功なし。 吉田 松陰(幕末の志士)