Linux 不是 Windows

Posted by & filed under Study & Reading.

!= ( Linux 不是 Windows) Derived works 如果你访问了这个页面,那么十有八九你是一个 Linux 的新用户,你正遇到许多关于如何由 Windows 转向 Linux 的困惑,这篇文章的目的正是向新手解释这个问题。由于这个大问题衍生出许多枝节,下面我将对此逐一进行讨论。 问题一:Linux 和 Windows 完全不一样 你一定会惊讶于有这么多人对 Linux 发出相似的抱怨,他们奔向Linux,希望找到一个免费的、开源版的 Windows。通常,这正是那些狂热的 Linux 使用者所告诉他们的那种状况。然而这却是个荒谬的期待。 人 们尝试 Linux 的原因不尽相同,但所有的原因都可以归结为一点:他们希望 Linux 会比 Windows更优秀。正是出于这一点,Linux的低成本、更广阔的选择范围、高性能和高安全性——当然,还有许多其它的方面——被作为与 Windows比较时的衡量标准。往往每一个开始尝试 Linux 的Windows 用户都是如此。 这正是问题之所在。 太 多的人都忽略了这样一个事实:从逻辑上讲,在保持某样东西与参考物体完全相同的前提下,将其做得更好是绝无可能的。正如一个完美的复制品将与它的母版毫无 差异,但是它不可能会超越原版。所以当你怀抱着 Linux 的使用方式该和使用 Windows 差不多的观念而尝试Linux,并希望它能够做得更好,你便会不可避免地发现他们之间的不同,并且把这些不同之处看作是 Linux 的缺陷。 举一个简单的例子,让我们来想一想驱动程序的升级吧:通常的情况下,倘若我们要在 Windows 下升级某个硬件驱动,我们需要去硬件制造商的网站上找到并下载最新的驱动;然而在 Linux 下,我们只须简单地升级内核即可。 这意味着在 Linux 下,仅仅一次下载和升级便能提供所有适用的最新驱动,然而在 Windows 下我们却不得不浏览多个网站并分别下载升级程序。这是一个不同的过程。并且显然,这绝不会是一种糟糕的体验。然而却有很多人对此抱怨不停,只因为这不是他们习惯的方式。… Read more »

包(package)建模技术

Posted by & filed under Programming.

当为较复杂的系统建模时,使用包是非常有效的建模方法。 包(package)在很多方面与类相似,但是在对大型系统建模时特别要注意区别包和类。类是对问题领域或解决方案的事物的抽象,包是把这些事物组织成模型的一种机制。包可以没有标识,因为它没有实例,在系统中不可见,类必须有标识,它有实例,类的实例(对象)是运行系统组成元素。 建立包图的具体做法如下: 1)分析系统模型元素(通常是对象),把概念上或语义上行进的模型元素纳入一个包。 2)对于每一个包,标出 每一个包,标出其模型元素的可视性(public、protect、private)。 3)确定包与包之间的依赖关系,特别是输入依赖。 4)确定包与包之间的泛化联系,确定包元素的多态性与重载。 5)绘制包图。 6)包图精化。

类图(Class Diagram)

Posted by & filed under Programming.

在UML的静态机制中,类图是一个重点,它不但是设计人员关心的核心,更是实现关注的核心。建模工具主要根据类图来产生源代码。类图在UML的9个图中占据了相当重要的地位。 James Rumbaugh对类的定义是:类是具有相似结构、行为和关系的一组对象的描述符。类是面向对象中最重要的构成模块。类图显示了一组类 、接口、协作以及他们之间的关系。在UML中,问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。类加上它们之间的关系就构成类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例。 类图是系统静态视图的一部分,它主要用来描述系统的静态结构。该视图主要支持系统的功能需求,也就是系统要提供给最终用户的服务。当系统分析师以支持软件系统功能需求为设计目的设计静态视图时,通常以下述三种方法之一使用类图。 1、对系统的词汇建模 为系统的词汇建模实际上是从词汇表中发现类,发现它的责任。 2、对简单协作建模 协作是指一些类、接口和其他元素一起工作提供一些合作的行为,这些行为不是简单地将元素相加能得到的。例如:当为一个分布式系统中的事物处理过程建立模型时,是不能只通过一个类来明白事物是怎样进行的,事实上这个过程的执行涉及到一系列的的协同工作。使用类图来可视化这些类和它们之间的关系。 3、对逻辑数据库模式建模 我们可以将数据保存到关系数据库或者面向对象的数据库,可以利用类图为这些数据库模式建立模型。

UML需求建模技术

Posted by & filed under Programming.

软件需求就是根据用户对产品的功能的期望,提出产品外部的功能的描述。 需求分析是的工作就是获取系统的需求,归纳系统要实现的功能,使最终的软件产品能最大限度地贴近用户的需求。需求分析师一般只要考虑系统做什么(what),而尽可能不去考虑怎么做(how)。 对系统功能建模可以参考如下方法: 1)识别系统的外部参与者,从而建立系统的语境。 2)考虑每个参与者期望的行为或需要提供的行为。 3)把公共性温命名为用例。 4)确定供其他用例使用的用例或扩展其他用例的用例。 5)在用例图中对这些用例、参与者和它们间guan关系建模。 6)用描述非功能需求的注释修饰用例图。

面向对象设计准则

Posted by & filed under Programming.

1、模块化 面向对象开发方法很自然地支持了把系统分解成了模块的设计原则:对象就是模块。它是把数据结构和操作这些数据的方法紧密结合在一起的模块 2、抽象 面对对象方法不仅支持过程抽象,而且支持数据抽象 3、信息隐藏 在面向对象方法中,信息隐藏通过对象的封装性来实现的。 4、低耦合 在面向对象方法中,对象是最基本的模块,因此,耦合主要指不同对象之间相互关联的紧密程度。低耦合是设计的一个重要标准,因为这有助于使得系统中的某一个部分的变化对其他的部分的影响降低到最低程度。 5、高内聚 1)操作内聚 2)类内聚 3)一般–>具体内聚

面向对象设计的启发规则

Posted by & filed under Programming.

1、使设计结果清晰、易懂、易读是提高软件可维护性和可复用性的重要措施。显然,人们不会复用那些他们不理解的设计 要做到: (1)用词一致 (2)使用已有的协议 (3)减少消息模式的作用 (4)避免模糊定义 2、一般——具体结构的深度要适当 3、设计简单类 应该尽量设计小而简单的类,这样便于开发和管理。为了保持简单,应注意以下几点: 1)避免包含过多的属性 2)有明确的定义 3)尽量简化对象之间的合作关系 4)不要提供太多的操作 4、使用简单的协议 一般来说、消息中的参数不要超过三个 5、使用简单的操作 面向对象设计出来的类中的操作通常都很小,一般只有3~5行源码,可以用仅含一个动词和一个宾语的简单句子描述它的功能 6、把设计变动减至最小 通常,设计质量越高设计节过保持不变的时间也越长。即使出现必须设计的情况,也应该使修改范围尽可能地小。

都是习惯……

Posted by & filed under Life Diary.

漫步在喧闹的街头,我找不到自己存在的理由。没有翅膀,我不会飞翔。左手握紧右手,抬头仰望蓝天,我找不到阳光的痕迹。可是我蹲下却看到时光的痕迹像一行一行蚂蚁穿越我的记忆。 邂逅了,相遇了,期待了,等待着收获。如果等待可以换来奇迹的话,我宁愿等下去,哪怕一年,抑或一生!习惯慢慢的成了必修的课程,无法离开,离开的也只是地图上的距离 一截断树残根,枯枝败叶 ,文字记录着残梦难圆疼痛。 幸福其实可以很简单,晚安,或是,早安。却永远相距那么一点距离,让你无法到达, 也可能是一瞬间,也可能是一生一世。 我们都是习惯的孩子……习惯的寻找着幸福,希望有一天可以大声的宣告:我已找到天堂!!!   原文