勇敢了

前天早上去买早点,抓住一个正在作案的小偷。那家伙拿着一个足有30厘米长的镊子,在从前面的一个中年妇女的包里夹东西。当时尽然大声的制止还把那个小偷推到了一边。只是抓住他的那一瞬间,感觉没有人和我站在一起。末了,我还有点心虚地补了一句:“这是我邻居”。那位中年妇女在买好早点后,说了声谢谢就走了。

虽说可以算作一件不值一提的小事,但有两个地方让我感觉很奇怪。

一是我当时的孤立的感觉,旁边(包括那位险些被偷的妇女)没有一个人能够一起制止那个小偷,我相信绝对不只是我看到了。
后来和老婆分析:那些真的看到了小偷作案而又莫不关心的,即便我和小偷发生正面冲突,9成也是不会出来的;而那些没有看到的,肯定也搞不清楚状况,反倒会成了看热闹的了。虽然我很不想承认,但不得不说这种想法是对人性的缺乏信心,是非常悲哀的事情。缺乏信心也许比冷漠本身还要让人感到悲凉。

二是,我最后补的那句“这是我邻居”的话,貌似一定要表示出有点关系才会制止 – 言外之意难道不认识就会任其作案吗?现在回想起来,当时还是有点胆怯了,俗话说明枪易躲暗箭难防,我在买好早点往家走的路上也会留意是否会有人跟梢。好吧,我不做任何辩解,我胆子小。

以下是忏悔,

应该是2008年的时候,有一次路过深圳罗湖,在小巴上亲眼看到一个小偷跟着一个正在上车的妇女,然后把她包中的钱包拿走跑下车去。在那短短的20秒钟的时间里,我胆怯了,没有做任何事。

以下是希望,

我比之前勇敢了,因为不止是我自己。

老文一篇

整理电脑时翻出很早以前在第二家公司时的写的一些东西。看着挺有意思,留着。看得出那时候自己还是很“爱公司”的。
貌似当时觉得公司的环境欠佳,想要去和老板说。不记得最终结果了。
I’d like to call the “environment” as “user interface”(UI)
UI is for the interaction between computers and human, our “environment” is for the interaction between client and us or employee and company, or you can say it is for both external and internal customers.
What we’ve discussed about too much is “professional” like:
No online chatting
No tailing gate
No visiting other block
No interrupting other people
No…
But, is that all? I don’t think so. We might ignore the “friendly” and “internal customers” –ourselves
To build a nice environment is not something serious, take it easy. Do we really need to make the workplace like battlefield?
The UI is very important for building people’s faith on the application, it is same that
The environment is important for building client’s faith on us and employees’ faith on company.
My opinion is, there should have some group like Quality group for the environment who will find the environment related problem ignored by most of us. And this platform should be open to all the employee, that is, everyone can submit the suggestion and all the suggestion will be proceeded appropriately and feedback timely.
if all  the employee can involve in, then we will achieve the status of “ever progressing”, which is really really exciting.
TO BUILD A PLATFORM TO LET ALL THE PEOPLE INVOLVE IN THE PROGRESSING OF THE COMPANY.
Sample:
Yesterday I found the poster near the ales entry looks awful, I will call the “environment quality group”
The quality group will do the action immediately and give me feedback.
I will feel good and do the same thing next time. 
–This is a very tiny thing, but if one’s suggestion is be appreciated he will enjoy that feeling, and do it again – this, is human nature.
all the above is “correct nonsense” (正确的废话)
But I would rather believe it is practicable.

UML中usecase之间的关系

老文。

 

用例描述的是系统外部可见的行为,是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲,用例之间都是并列的,它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看,我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息,然后通后过不同的方法来重用这部公共信息,以减少模型维护的工作量。

 

泛话(继承)就不说了很好理解.

 

包含(include) 

 

包含关系是通过在关联关系上应用<<include>>构造型来表示的,如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion),具体地讲,就是将被包含用例的事件流插入到基础用例的事件流中。

 

扩展(extend) 

 

扩展(extend)关系如下图所示,基础用例(Base)中定义有一至多个已命名的扩展点,扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。

至少从这个两个定义里面都看到了”将扩展(被包含)用例的事件流插入基础用例事件流”, 也就是 如果 用例A include 用例B, 似乎就又可以描述为 用例B extend 用例A, 是这样吗?

前一分钟, 我问了从我身边经过的一个同事这个问题, 他的答案是:可以把extend理解为并联,include理解为串联. 也就是说 include所包含的用例必须是基础用例的一部分,没有他基础用例就不完整. 而extend则意味着扩展, 可以扩展用例插入到任何扩展点.或者说 “对于包含关系而言,子用例中的事件流是一定插入到基础用例中去的,并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流,并且插入点可以有多个。”