ビジネス備忘録（PoC研修）

肌がきれいになったと褒められました、けんとです。
文系出身、プログラミングの超初心者のリアルな箇条書きメモ。
週単位でヘッダーを変えることにしました、日々改良です。
今週もやっていきましょう！！

/*システム開発とソフトウェア開発*/
システム開発：業務の仕組みを改善するシステムの開発
ソフトウェア開発：プログラム・ソフトウェアの開発

引用：https://oshiete.goo.ne.jp/qa/600833.html

/*オブジェクト指向*/
モノの作成と操作としてみる考え方
テレビを操作するとき、中でどういうプログラムが動いているかは知る必要はない、リモコンで操作すれば動く
Ａボタンを押せば動く、Ｂボタンを押せば止まる
そんなイメージや概念をプログラミングの世界でも応用している

以下、「ポリモーフィズム」のワードまで下記のサイトを引用した
https://eng-entrance.com/what-oop

/*クラス*/
オブジェクトの設計書のようなもの

/*プロパティ*/
オブジェクトが持っているデータのこと
属性という
例えば車にはメーカー、排気量、色といったプロパティがある

/*メソッド*/
オブジェクトが持っている処理のこと
例えば、車だと走る、曲がる、止まるといったアクションを起こす処理がある
このアクションのことを「振る舞い」というケースもある

/*インスタンス*/
オブジェクトを実際に使うときに生み出されるもの
設計書からオブジェクトを作ることをインスタンス化と呼ぶ

/*カプセル化*/
ステルス化
別のオブジェクトから利用される必要のないものを隠すこと
プログラムが壊れにくくなる、大人数で開発をするときすべてのコードを認識する必要がなくなる、といった利点がある

/*継承*/
特定のオブジェクトの機能を引き継いで使うこと
例えば、レーシングカーは車の機能を継承している
サンプルコードの利用も継承

/*ポリモーフィズム*/
クラスによって同一のメソッドで異なる処理が行える性質のこと

/*UML*/
ソフトウェアの機能や構造をわかりやすく図解したもの
大枠で２種類のパターンがある
・システムの構造を表す構造図（strcture diagram）
・動作や変化を表す振る舞い図（behavior diagram）
引用：https://medium-company.com/uml/

/*コンポーネント図*/
処理を構成するクラスをまとめ、コンポーネントと見なす
それを図解したもの
Ｕ→入力（要求側インターフェース）
〇→出力（提供側インターフェース）

書き方は以下のリンクがわかりやすかった
参考＆引用：http://www.itsenka.com/contents/development/uml/component.html

/*シーケンス図*/
オブジェクトの流れがどのように流れているのかを時系列であらわす図
書き方は以下のリンクがわかりやすかった

書く際の手順は以下
・ライフラインを決める
・要求メッセージ
・応答メッセージ
・各メッセージに処理の説明を記述する

参考：https://medium-company.com/uml/

/*ユースケース図*/
ユーザー視点でシステムの利用例を表現する図解術


/*caps lockキー*/
Caps Lock + Shift で操作可能

/*コンポーネント図*/
追記
各コンポーネントは、システム全体の１つの明確な目的に責任を持ち、必要に応じて他の重要な要素とのみ対話します

コンポーネントを洗い出す
各コンポーネントが提供する機能を洗い出す
各コンポーネントが必要とする機能を洗い出す
提供する機能と必要とする機能をつないでいく

ハード的な視点の場合は、
・箱とインストール品を明記する
・ソフトとデータは分ける、あくまでツールを明記
・部品数とつながりを見える化するのが目的
・厳密さより活用することが大事

引用：http://agile.blog.jp/agile_scrum/14996994.html
https://www.slideshare.net/TakaoSumitomo/uml-52883154