All posts by yuya

新入生歓迎LT祭り 2014 に参加

こんばんは.
安里@M1です.

 

今日は
新入生歓迎LT祭り 2014
に参加しました.

自己啓発系や技術系,作曲やお絵描き,遊び などなど・・・
様々なジャンルのプレゼンを行っていました.

あと,私と太田さんが発表者として舞台に立ちました.

新入生は20人くらい居たみたいですね!
意外と参加してる人が多くてよかったですです.

 

 

 

・・・あーっ!
写真撮るの忘れてたー/(^o^)\

新入生向けインストール大会

安里@M1です.
こんにちは

4/7に新入生向けのインストール大会がありました.
4月から正式に配属された長田研の杉本,仲井間,西村が司会・進行役をつとめていました.

image2

 

みなさん新しいPC受け取ってはしゃいでます
なんか初々しいしかったですね
僕にもあんな時期があったのかーって思うと
なんだか歳をとったなーって気分になってます

少しトラブルもありましたが
無事インストール大会も成功に終わりました.

新入生のみなさん
これからの成長に期待しています

 

 

僕は,部屋の隅っこでインストール大会してました(笑)

image3

 

 

 

UML (ユースケース図) アドベントカレンダー (7日目)

こんにちは。 安里悠矢@長田研(仮)B4です。
内容は、前回の続きということで、ユースケース図について書きたいと思います。

———————————————————-

もしあなたがシステムを何も無い状態から作っていく場合、何から始めますか?
誰がシステムを使うのか、どの機能が必要かなどを検討するなど、要求分析をする必要がありますよね。
ユースケース図では、今から作成するシステムで実現すべきことを明確にするために用いられます。

ユースケース図

ユースケースとは、今から作成するシステムで実現すべきことです。ユースケースの表記方法は複数ありますが、一番左の楕円の中にユースケース名を配置する方法が一般的でしょう。

上の図は、システムがアクターに対して「データを登録する」という機能/振る舞いを提供することを意味します。

アクター

アクターは、作るシステムの利用者のことです。棒人間みたいな図で記述されます。
利用者といっても、人だけじゃなくて、ハードウェアだったり外部システムといった人間以外の要素も含まれます。

ユースケースの包含 (include)
「包含(ほうがん)」は、複数のユースケースから共通利用されるユースケースとの間に存在する関係です。

例えば、データを登録や削除には、一度認証処理を行わないと行けないようなシステムがあるとします。
このシステムの場合、「本人認証を行う」ユースケースはどちらでも利用されるので、<<include>>を用いて記述します

ユースケースの拡張(extend)

条件付きで他のユースケースを利用する場合、<<extend>>を用いて表現します。

例えば、データを検索してる際に、ユーザがファイルへの出力を行う場合、<<extend>>を用いて、条件付きで記述します。

ユースケースの汎化

「ユースケースの汎化」は、一方が他方の機能を継承する関係を表現したものです。
例えば、「ユーザを検索する」というユースケースに、「IDで検索する」だったり、「キーワードで検索する」という方法があるとします。どちらも「ユーザを検索する」という共通の機能を持っています。
汎化は、個別機能を持つユースケース側から共通機能を持つユースケース側へ、白抜きの三角形がついた矢印を用いて表現します。

アクターの汎化
「アクターの汎化」もユースケースと同様に、一方が他方の機能を継承する関係を表したものです。
例えば、「社員」というアクターに、「使える社員」や「使えない社員」というアクターがあったとします。
どちらも「社員」なので、汎化関係にあると言えます。
基本的なことについてはこんなものかな….

ユースケース図を描くときのポイント

①分析中毒にならないようにする
最初から完全に分析できるものではないです。気楽にやりましょう。
②ユースケース名は動詞で表現する
内容の曖昧さを無くすために、「〜する」とか動詞を入れましょう。
③作成/読み込み/更新/削除のユースケースは、「管理する」でまとめる
ユースケースが増えすぎて、図が読みづらくなります。なので「管理する」でまとめちゃいましょう。
④詳細すぎないようにする
ユースケースは、あまり詳細に書く必要はないです、汎化のように抽象的に描いたほうがいいです。
今日はこんなところで終わります。
次回担当の際は、クラス図とかについて書こうかな。

UML (長田研アドベントカレンダー4日目)

こんにちは。 安里悠矢@長田研(仮)B4です。

何を書くか結構迷ったんですが
自分がETロボコンに参加してたので、UMLについて書きたいと思います。



UML (Unified Modeling Language)とは?

簡単に言うと「プログラムの設計書」です。
1990年代の初めは、プログラムの設計書の表記法が統一されていなくて、複数の表記法が乱立していました。
複数の表記法が乱立していると、表記法について毎回勉強しないといけないし、プログラム作るのも大変だし…
ってことでUMLという統一された表記法が確立されました。



UMLってそんな大事?プログラム書けりゃいいじゃん!

自分も初めはそう思ってました。
UMLがなぜ必要なのか?
教科書見てみると大抵は以下のことが書いてある
  • システムに求められる要求の高度化と多様化
  • システムの大規模化と複雑化に対応するため
  • 関係者間でのコミュニケーションの難しさ
….うん?って感じですね。
いろいろな教科書を見てきましたが、もっと難しいこと書いてある教科書もありました。
実際、UMLとか使って仕事している人にはこの意味が分かるかもしれないけど、
勉強し始めの頃は何を言ってるかわかりませんでした(多分今でもよく分かってない)
少し話は変わりますが….
もし、あなたが誰かに自分の作ったシステム(アプリケーションとか、プログラムとか)をレビュー(評価)してもらいたいとき、どうしますか?

プログラムを見せる!

それもありでしょう。
相手がプログラムをバリバリ書ける人なら適切なレビューが貰えるかもしれません。
しかし、相手がそのプログラム言語についての理解が浅かった場合、適切なレビューを得られないでしょう。
もしかしたらレビューすら貰えないこともあるかもしれません。

UMLを見せる!

相手がそのプログラム言語について理解している必要はほとんどありません(理解してることにこしたことはないですが)。
表記法については多少理解している必要があることもありますが
UMLの表記法は意外と簡単なので、分からない人にもすぐ説明できるでしょう。
プログラムよりもレビューは得られやすい。
また、そのレビューしてもらいたいシステムが本当に動くものなのか。
一緒に考えてもらえるきっかけにもなります。



UMLがなぜ必要なのか?

一番はこういうことだと思っています。
プログラムをガッツリ書けない人とでも、システムの妥当性を一緒に検証できる(考える)場を得られるから必要だと感じています。
やっぱり動くものを作るプログラマーは偉いと思います(実際にシステムを作っているし)
ですが、UMLも書けてこそできるプログラマーになれるのではないかなと感じます。


実際にUML書いてレビューさせるとダメ出しが多いし
プログラムみたいに動くものではないから達成感もなかなか得られないし
心折れることのほうが多いかもしれませんが
やっぱり大事な気がします



今回は技術的なことは一切触れてませんが、次回からやっていこうと思います。