文档结构  
翻译进度:58%     翻译赏金:0 元 (?)    ¥ 我要打赏
参与翻译: 城府很深 (6), lucky (1)

软件设计很重要,它是一个应用程序的基础,就像一个蓝图,它为各个背景下的参与方提供一个公共平台,它促进理解、合作和发展。

设计不应该仅仅被看做是开发的一个元素,它不应该仅仅存在于开发者的脑海中,否则的话,团队就几乎无法获得成长,就像知识很难获取一样。另外,当员工离开,这家公司将会失去更多的价值。

应用程序代码应该通过有效地把邻域模型转化为明确的抽象来描述设计。这些东西应该被良好的编码,被准确的命名以及被正确的定义。然而,有这些仍旧不够。

 

第 1 段(可获 1.29 积分)

设计不能仅停留在代码里面,使用这个层次来表达设计对开发团队可能是足够的,但对其他可能对应用程序设计感兴趣的人而言是行不通的。他们要么实际上不能得到代码(他们没有软件开发的经验),要么只是没有时间去亲自实现设计。

在编写大量代码前,有时一个高层次的设计需要在一个多团队组织里面进行讨论和完善。在这种情况下,它变得清晰,设计不能仅仅只包含在代码里面,尽管代码展现了它。因此,设计建模成为了一个独立的过程。

第 2 段(可获 1.48 积分)

表达系统设计

设计不仅仅是关于类,以及它们如何相互关联。它也是关于协作和行为。关于用例、状态和活动。

通信设计的主要形式如下。UML 被用来作为参考由于它的受欢迎程度,然而,任何人都不应该受限于它的符号或术语,因为有效的沟通才是重点。

结构

概述图

系统结构概述使用一组描述部署策略、软件包、模块和组件的图表进行描述。

第 3 段(可获 1.11 积分)

One of the highest level overviews is deployment, described in terms of infrastructure entities used by the application. UML describes deployment diagrams to achieve that purpose, consisting of nodes, e.g., web server, application server, database server, and clients.

The components deployed in a system have external dependencies. These should be documented. UML prescribes package diagrams for this purpose, which describe package merge and import relationships.

Detailed Diagrams

At a lower level, the system’s structure is described by showcasing the classes and the relationships between them.

第 4 段(可获 1.09 积分)

类图

类图描述系统的类,包括它们的属性,操作(或方法),以及它们之间的关系。

关系可以是多种类型的 比如依赖、关联、组合、继承。必须明确的表达它们,这样,团队的开发人员才能根据这些类图手动或者使用自动化类生成工具去设计系统。

UML中, 类成员可以有以下类型的可见性:

  • Public: +
  • Private: -
  • Protected: #
  • Derived: /, 该属性是从另一个元素的该属性计算得到
  • Package: ~
第 5 段(可获 1.14 积分)

在UML里面,如下关系被定义:

  • 关联(Association): 代表一系列的链接关系, 它们可能是单向的或者双向的; 关联可以被命名;
  • 泛化(Inheritance / Generalization): 一个类是另一个类的一个特殊形式
  • 实现(Realization / Implementation):一个类实现一个接口
  • 依赖(Dependency): 两个元素之间发生一种单向的关系当改变一个元素导致另外一个元素也需要改变
  • 聚合(Aggregations): 一中’有一个‘的关系,这种关系只可能是双向的; 在聚合关系中,聚合组件可以存在于容器之外
  • 组合(Composition): 一个更强大的聚合关系,在这种关系中,聚合组件不能存在于容器之外 ,比如说汽车的引擎

 

第 6 段(可获 1.36 积分)

Class Structure Diagrams

This type of diagram displays the internal structure of a class. They can include how its collaborators interact with it and with each other.

In UML, the composite structure diagram includes internal parts, ports, and connectors. Ports facilitate communication within the class’ parts and with the outside world. Connectors lie between parts and ports.

The composite structure diagram for a Fibonacci system is presented below:

Interactions

The interactions that take place within a system are as important as its structure, if not more. In reality, the behavior is what users experience, so having it described precisely and modeled early can save everyone involved in the project a lot of headache.

第 7 段(可获 1.41 积分)

Use Cases

Users interact with systems in order to satisfy an objective. The set of interactions required to fulfill an objective forms a use case.

Representing these interactions is very important for visualizing requirements in a compact form, as opposed to a set of user stories. UML defines the use-case diagram, which involves the different actors and the system.

Interaction Overview

At a higher level, the system can be described in terms of interactions between its modules, usually to model control flow. To that extent, UML defines the interaction overview diagram and the activity diagram. Interaction overview diagrams can describe a control flow composed of multiple interactions, while activity diagrams go a level of detail lower, describing the actual conditions, logic, and actions.

第 8 段(可获 1.54 积分)

Detailed Interactions

The order of operations between collaborating classes is captured by a message sequence diagram; in UML, they are called sequence diagrams. These types of diagrams describe not only how the classes interact, but also include a temporal element, establishing the order – or sequence – of interactions:

The horizontal arrows display the messages exchanged between the two collaborators. The vertical lines, also called lifelines, capture all the communication that can occur between the two classes.

State

System state might be hard to visualize in an environment with complex constraints and conditions. Most intuitively, the system can be represented as a state machine with as many nodes as there are states and the conditions switching between states attached to the arrows marking the transition. For increased readability, complex conditions should be abstracted and expressed in concise terms.

第 9 段(可获 1.7 积分)

UML中,状态图使用标准化的符号来表示状态。 实心圆表示初始状态。空心圆表示最终的状态。 一个圆角矩形代表一个给定的、命名的状态,箭头表示转换,关联至给定名称的事件:

建模技术

设计可以使用两种基本的方法进行描述,文本和图形。 通常情况下, 人类更倾向于使用图形,但是文本模型更具描述性。混合使用两种方法,可以同时兼具一个高级的概述和可视化细节的能力。

.

第 10 段(可获 1.15 积分)

Textual modeling is performed expressing requirements in a formalized language. These models tend to provide more details at the expense of overall overview. Creation speed is considered in some circles to be higher than with graphical methods because in graphical methods the designers need to switch between mouse and keyboard. Formatting tends to be much faster and of higher quality. Also, the use of versioning comes much more natural, given the text-based format.

However, with textual modeling, understanding a module tends to be a more challenging task. More modern tools have provided means to display a tree-based structure or state machine to overcome this problem, but that is not always enough. One particular problem that cannot be tackled remains animation and simulations, which, if needed, should be considered as grounds for moving to a graphical method.

第 11 段(可获 1.7 积分)

使用图形建模,用户除了使用建模工具外无须学习任何其他东西。设计与编程不一样,因为他们涉及更多的是建模的概念。当学习一个系统时,从顶层到底层然后再返回到顶层会更加容易。

总结

通信设计和设计一样重要。必须避免保持设计在开发人员的头脑中和/或者代码中。相反,它应该是有效的通信,这样每一个参与项目的人都可以访问它。

第 12 段(可获 1.18 积分)

文章评论