当今的架构师和架构
引言 |
在计算机的早期,大概是1960年左右,硬件的花费在软件之上,是占主导地位的。40年之后,我们发现情况发生了极大的变化。
因为工业的进步,硬件的成本急剧的下降。另一方面,软件开发的成本因为个性化企业级应用开发的复杂性而急剧上升。对公司来说,便宜的硬件使得为他们的信息系统增加越来越多的功能是值得的。最初一些独立的系统,相互之间没有连接,也很少会共享数据,在多年之后,变成了复杂的系统,功能和模块之间相互连接。
这种情况创造了一个需求,在进行这样的系统设计的时候,需要一系列的规范来指导工程师。
从建筑行业借用过来,“架构”一词用来描述计划、设计、实现软件系统的技能,是合适的。然而,在软件开发中,架构不像在建筑行业中需要那么多的艺术性质。设计良好的建筑对眼睛和功能来说,是令人愉快的。软件架构在主观方面会少一点。
正文 |
1、什么是软件架构
“架构"一词最初被用于软件工业中,是表达在进行代码开发之前需要计划和设计。但是,在架构一个可用的软件系统和架构一个适于居住的建筑之间还是有本质的区别的。
很明显的,在架构建筑的过程中,我们会考虑建筑是否会砸到人。但是在软件中,通常有大量的金钱可以改写一个架构。在建筑业中,设计一定要以极其详细的计算和蓝图为基础,才能完成。在软件开发中,你可能会倾向于更加敏捷。在十几年前,预先设计的方法在软件行业也是非常普遍和流行的。但是,十几年过去了,这种方法增加了开发成本。因为在部署之前,软件可以进行高效和安全的测试,相比预先设计,敏捷占了上风。
今天,建筑行业的架构和软件行业的架构已经不像很多年前那么相似了。在很多字典中,软件架构被描述为:在一个计算机系统中,组合、整合、多个组件之间的联系。但是,他还是比较抽象的。
软件行内人通常会接受另一个解释:将系统分解为很多小块,然后放在环境中。
2、谁是架构师
架构设计基于对需求的分析。分析可以确定系统需要做什么,架构可以确定如何做。架构师是需求和详细设计之间的纽带,但是架构师的职责是什么呢?需要哪些技能呢?
2.1架构师的职责
根据ISO标准中定义,架构师是对系统架构负责的人、团队或者是组织。架构师与分析人员和项目经理相互配合,对系统评估和提出建议,协调一队开发人员。
架构师参与开发的整个过程,包括分析需求和架构设计、代码实现、测试、集成和部署。
主要的职责包括:
1)理解需求
在软件项目中,在架构师参与之前会发生一些其他事情。一群分析人员,IT部门的管理者,行政部门会开会、讨论、评估、商量。一旦一个新系统的需求被确定下来,预算到位,分析人员就会基于自己的业务知识、企业的流程、环境和终端用户的反馈引出典型的需求。
需求列表准备好之后,项目经理就会和架构师碰头,将需求交给架构师,“这就是客户想要的,你去构建一下”。
架构师理解需求,尽力在设计中满足和采纳它们。
2)分解系统
在需求的基础上,架构师将系统分解为多个子系统。在这种情况下,架构师会展望一下逻辑层和服务层。然后基于环境,确定层之间的接口,和其它层之间的关系,系统需要的服务级别。
整体设计与企业的目标和需求保持一致。在一些特殊地方,由需求来驱动整体设计,而不是整体设计领导需求。
架构会包括一些通用的指导原则,要求最小化模块之间的耦合,保持模块的高内聚,保证每一个模块有一个清晰的职责。
架构的结果还会满足一些非功能的需求,例如:安全、伸缩性。最后架构师还会指定一些战略性的东西,例如:每一个开发者的任务、或者是团队的任务,或者是子系统的组件。
3)确定和评估可用的技术
在理解了需求和设计了系统的层次之后,下一步就是用具体的技术和产品计划逻辑组件。架构师应该清楚和项目有关的产品和技术的成本和好处。架构师推荐一些对于项目来说,性价比较高的产品和技术。架构师不决定技术,只是以自己的知识为基础,推荐技术。
那么谁来决定使用架构师推荐的那种技术呢?显然是项目经理,或者是预算的管理者。架构师的建议可能被接受或者被否决。
4)明确详细设计
架构师最后的职责就是确定详细设计,详细设计是架构师和开发者进行交流的结果。详细设计可以以多种形式存在,UML图、文档、Viso图,甚至是原型。沟通对于一个架构师来说是至关重要的。沟通发生在架构师和开发者之间,也发生在架构师和项目经理以及业务分析人员之间,但是不是和用户。对架构师来说,一个良好的技术就是语言清晰。
结论 |
架构是一个被广泛使用的词汇,拥有相当多的定义。
架构设计从功能和非功能需求出发,功能由业务分析员收集,架构师理解。
UML概要
引言 |
设计一个系统,任何科学领域的系统,你首先需要做的是对它进行抽象。抽象模型为系统的视图、结构、行为、参与实体和流程方面具体的实现提供一个代理。在系统的参与人员(包括:开发者,架构师,所有者,用户)之间应该共享一个模型。为了能够提出反馈,提出错误的假设,改进建议,模型应该能够被系统的参与者所理解。尽管共享了一个模型,你还是需要用一种通用的,被广泛接受的的形式和符号来表达模型。例如:模型语言。
显然,建模语言是基于一系列规则、符号、图表和关键字的图形或者文字语言。语言的元素用来表达模型的结构和行为,给任何熟悉语言的人传达清晰的认识和信息。
有很多著名的建模语言例子,最流行的一个就是UML(Unified Modeling Language 统一建模语言)。UML是一种通用的图形建模语言,在过去的很多年,已经变成了工业的标准。UML特别适合于建立面向对象的系统。
正文 |
1、简介
建模在任何软件项目中都是一个关键的阶段,对于大型的、企业级的应用更是至关重要。
在复杂的情况下,模型是一个本质。它可以帮助检查详细设计的正确性和遵守程度,使得软件可以更加容易的构建和维护。一个清晰的、良好的模型同样可以在任何时候帮助开发者找到断点的正确位置,并且修复bug。在软件中,模型应该和站点地图、蓝图同样重要,它是必须的,而不是一个可选的工具。
2、UML的优缺点
在现实世界,没有东西比公认的标准更加吸引公众的批评。令每一个人都满意确实很难。UML也不例外。尽管到目前为止它是使用最广的建模语言,但是从根本上来说它是一个臃肿的语言。毫无疑问,1.0需要改进,2.0有了提高。但是一些人还是认为2.0还是很臃肿和复杂,还是很难学习。
3、在实践中使用UML
该要的说,使用UML你需要一个方法来收集和分析需求,然后用建模工具转换为模型。通常,建模工具有自己的方法,你只需要找到最适合自己的工具就可以了。类似的工具有很多,包括:微软的Viso,IBM的Rational Rose,Sparx Systems的EA。
4、UML中的图形
UML2.0包括13中不同的图形,分为两组:行为和结构。结构图定义类,属性,操作和关系。行为图显示系统中对象的协作关系。
图 | 组 | 目的 |
活动图Activity | 行为 | 显示一个活动中的操作流程 |
类图Class | 结构 | 显示类、接口、及他们的关系 |
Communication | 行为 | 显示对象之间的交互 |
Component | 结构 | 显示组件和他们之间的依赖关系 |
Composite Structure | 结构 | 显示类的内部结构 |
Deployment | 结构 | 显示组件如何映射到硬件资源 |
Interaction Overview | 行为 | 显示顺序和活动 |
Object | 结构 | 显示系统在特定时间的状态 |
Package | 结构 | 显示类如何分布在逻辑的相关组中 |
序列Sequence | 行为 | 显示对象之间的交互 |
State machine | 行为 | 显示在事件发生之后,对象的状态如何变化 |
Timing | 行为 | 显示在特定时期中,对象的行为 |
Use Case |
行为 | 显示参与者在系统中进行放入操作 |
UML图之间的等级关系
4.1用例图Use Case
用例图提供了一个图形化的用例描述。一个用例图代表一个或者多个参与者和系统之间的相互作用。用例图显示了参与者要做的事情。一个参与者可以是一个人,也可以是和系统进行交互的任何外部系统。参与者不受系统控制,参与者是在系统之外定义的。
用例图主要包括:系统,参与者,用例,关系。
上图就是一个用例图,有两个参与者和两个用例。两个参与者分别得用户和数据库,两个用例分别是获取订单,获取商品的详细信息。
4.2类图
类图在UML使用较为广泛。类图代表系统的静态结构。系统的静态结构由类和他们之间的关系组成。
类图包括属性,操作,和关系。关系则包括我们常说的1:1,1:n,0:1,0:n,n:n等
上图是一张类图,有三个类:Customer用户,Order订单,OrderDetail订单明细。
Customer上面有三个属性:CustomerID,CustomerName,Address。CustomerID是public,前面的符号是+;CustomerName是protected,前面的符号是#;Address是private,前面的符号是-。
连接类之间的线代表他们之间的关系,也就是我们常说的1:1,1:n,0:1,0:n,n:n,0:n其中之一,关系还区分从哪个类的角度来看。图中的Customer和Order的关系,从Customer角度来看,一个Customer可以没有Order,也可以由多个Order,所以他们之间就是0:n的关系;从Order角度看,一个Order肯定属于一个Customer,所以他们之间就是1:1的关系。
一个Order肯定有一个以上的Detail,一个Detai肯定属于一个Order。
上面的类图是在PowerDesigner中画的,下面是自动生成的c#代码,当然了,肯定是需要调整的。

// Author: zy
// Created: 2010年8月6日 6:40:04
// Purpose: Definition of Class Customer
using System;
public class Customer
{
private string address;
protected string customerName;
public Customer GetCustomerByID()
{
throw new NotImplementedException();
}
public int GetCustomerOrders()
{
throw new NotImplementedException();
}
public int customerID;
public System.Collections.Generic.List<Order> order;
/// <summary>
/// Property for collection of Order
/// </summary>
/// <pdGenerated>Default opposite class collection property</pdGenerated>
public System.Collections.Generic.List<Order> Order
{
get
{
if (order == null)
order = new System.Collections.Generic.List<Order>();
return order;
}
set
{
RemoveAllOrder();
if (value != null)
{
foreach (Order oOrder in value)
AddOrder(oOrder);
}
}
}
/// <summary>
/// Add a new Order in the collection
/// </summary>
/// <pdGenerated>Default Add</pdGenerated>
public void AddOrder(Order newOrder)
{
if (newOrder == null)
return;
if (this.order == null)
this.order = new System.Collections.Generic.List<Order>();
if (!this.order.Contains(newOrder))
this.order.Add(newOrder);
}
/// <summary>
/// Remove an existing Order from the collection
/// </summary>
/// <pdGenerated>Default Remove</pdGenerated>
public void RemoveOrder(Order oldOrder)
{
if (oldOrder == null)
return;
if (this.order != null)
if (this.order.Contains(oldOrder))
this.order.Remove(oldOrder);
}
/// <summary>
/// Remove all instances of Order from the collection
/// </summary>
/// <pdGenerated>Default removeAll</pdGenerated>
public void RemoveAllOrder()
{
if (order != null)
order.Clear();
}
}

// Author: zy
// Created: 2010年8月6日 6:43:42
// Purpose: Definition of Class Order
using System;
public class Order
{
private string orderSeqNo;
private decimal orderAmount;
private int customerID;
public System.Collections.Generic.List<OrderDetail> orderDetail;
/// <summary>
/// Property for collection of OrderDetail
/// </summary>
/// <pdGenerated>Default opposite class collection property</pdGenerated>
public System.Collections.Generic.List<OrderDetail> OrderDetail
{
get
{
if (orderDetail == null)
orderDetail = new System.Collections.Generic.List<OrderDetail>();
return orderDetail;
}
set
{
RemoveAllOrderDetail();
if (value != null)
{
foreach (OrderDetail oOrderDetail in value)
AddOrderDetail(oOrderDetail);
}
}
}
/// <summary>
/// Add a new OrderDetail in the collection
/// </summary>
/// <pdGenerated>Default Add</pdGenerated>
public void AddOrderDetail(OrderDetail newOrderDetail)
{
if (newOrderDetail == null)
return;
if (this.orderDetail == null)
this.orderDetail = new System.Collections.Generic.List<OrderDetail>();
if (!this.orderDetail.Contains(newOrderDetail))
this.orderDetail.Add(newOrderDetail);
}
/// <summary>
/// Remove an existing OrderDetail from the collection
/// </summary>
/// <pdGenerated>Default Remove</pdGenerated>
public void RemoveOrderDetail(OrderDetail oldOrderDetail)
{
if (oldOrderDetail == null)
return;
if (this.orderDetail != null)
if (this.orderDetail.Contains(oldOrderDetail))
this.orderDetail.Remove(oldOrderDetail);
}
/// <summary>
/// Remove all instances of OrderDetail from the collection
/// </summary>
/// <pdGenerated>Default removeAll</pdGenerated>
public void RemoveAllOrderDetail()
{
if (orderDetail != null)
orderDetail.Clear();
}
}
结论 |
UML是一种标准的对象建模语言。它独立于任何编程语言。这是一个关键的特性,既是一个优点,也是一个缺点。说它是一个优点,是因为它使得在使用UML进行建模以及表达业务流程的时候,变成一个非常强大的工具。同时可以用它产生一个通用的模型。缺点就是因为优点产生的,独立性越强,也就越是远离了系统运行的代码。