架构师速成6.7-设计开发思路-uml

uml是什么东西?统一建模语言。一门语言。是用来进行软件设计的一门语言。

事实上一门语言的诞生并不伟大,让大多数人都使用才足够伟大。

uml就是一门伟大的语言。由于眼下软件设计的唯一语言就是它。

UML事实上还是比較简单的,就那么几个图形,那么几种模式。可是由于他是唯一的语言,所以有设计能力的人都能非常easy看懂你说的什么,这就是他的伟大之处。

我说一下在软件设计中最经常使用的几个,以及我的心得:

  1. 用例图,在了解用户需求时非常有效,他仅用来描写叙述系统须要提供的功能,本身没有顺序,不要用来描写叙述流程。注意使用扩展和包括。

    那个小人即能够是使用者也能够是其它系统。
  2. 类图,这是面向对象设计的真谛,不要和ER图混为一谈,类图是用来描写叙述类与类之间的交互关系,本身能够没有不论什么属性。当然也能够有非常多属性,可是不要用设计数据库的思路来设计类图。类图仅仅是用来反映现实。在设计类图时。能够觉得数据会存储在DB中,也可能存储在XML中,也能够存储在文件里。不要去考虑存储。
  3. 对象图,用的不太多
  4. 序列图。描写叙述对象之间的交互顺序,着重体现对象间消息传递的时间顺序,这个比較实用。可是不是非常难。
  5. 状态图,状态机就是它了。当你被复杂的状态搞晕的时候。用它来画清楚,实现就用状态模式。perfect。
  6. 活动图,表示两个或多个对象之间在处理某个活动时的过程控制流程,这个也非常重要,可是不难。

其它我用的就不多了。学习这门语言真的非常重要。请重视。掌握他之后,学习设计模式会更加得心应手!

时间: 2024-10-26 17:31:44

架构师速成6.7-设计开发思路-uml的相关文章

架构师速成6.3-设计开发思路

面向对象,是一个伟大的设计思想,应该是软件开发史上的一次革命. 当然理解面向对象也很难,有好多人用着面向对象的语言,写着面向过程的逻辑,而且一写就是好多年.但是有高手,用c照样可以写出很牛的面向对象的程序.面向对象其实是一种思考问题的方式,重点如下: 面向对象是用来反映显示世界的,而不是强行创造世界. 这句话,说起来简单,但是做起来很难.现实世界中你绝对不会把狗腿,按在一个人身上,但是写程序的时候,你常常会创造出一个狗腿人. 有人还会创造一些一些稀奇古怪的万能类,或者融合了n种物种的怪物.或者只

架构师速成-架构体系

经过这段时间的反思和整理,终于对架构有了一个较为明确的理解.架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称,架构过程: 配置.编码.测试.运维.监控分析.安全.运营等一系列技术体系的选型.取舍 技术选型基础上进行规划.设计.实现.迭代.制定相关规范 相关技术及规范运用到产品开发的整个过程中,并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架,比如有人用了spring就觉得我已经是架构师了,其实架构并不是这么简单.我们以做一个新浪微博类似产品为例,现实应该是这样的: 产品初

架构师速成7.3-devops为什么很重要

evops是一个很高大上的名字,其实说的简单点就是开发和运维本身就是一个团队的,要干就一起把事情干好.谁出了问题,网站都不行.作为一个架构师,必须要devops,而且要知道如何推行devops. 首先要自动化,举个阿里的例子,阿里通过aone系统来实现半自动化部署: 开发人员开发代码先自测通过后,提交代码到git. 在aone中一键部署到日常环境.部署是自动化扫描依赖冲突,系统安全等问题. 测试接到部署成功的通知,进行测试,如果测试通过,则审批通过,可以线上发布. 线上运维人员一键部署到线上,部

架构师速成5-小学

很高兴你很快的进入了小学,小学的东西会让你更加的耀眼. 阶段: 小学 学时:2-3个月 升学标准 能自己制定目标及计划,get thing done. 可以轻松制作一个让你身旁人惊叹的ppt 能做一个简单的网站(或者客户端软件),数据能保存到数据库. 实践经验干货来了. 先说ppt吧,这个上一期已经讲了,如果你ppt做到出神入化,基本不需要做架构这么苦逼的事情了.因为你很容易成为老板的心腹,军师,走上人生正道.作为一个苦逼的小学程序员,很羡慕吧.那就再努力学一下,不用多久,你就会升职加薪,当上总

架构师速成7.4-架构师为什么要带团队

有人说架构师明明只需要做架构,干嘛要扯出来带团队,带团队不是项目经理或者CTO之类的管理人员干的事情吗? 其实这个是一个误区,架构师其实是一个全栈的特殊人物,应该项目开发的所有的环节和角色都有深入了解,尤其是带过团队对你的帮助会更大.那种只做架构,而且仅会做架构的架构师,是大公司畸形的产物,在我看来,不太接地气.大公司人员体系庞大,分工明确而且细致,技术只是负责技术就好了,管理自然有专门的管理人员来做.我简单列举一下架构师带团队的优势: 架构设计时会从整个项目的角度考虑 开发人员使用更方便 测试

架构师如何才能够设计一个安全的架构

架构师不可能做到全知全能,但是仍然担负着成功交付可用的解决方案的任务.满足安全需求常常是其中不可或缺的一环,而且这一点常常没有明确指出.下面我们从整体上讨论架构的安全性,比如如何撰写安全的代码.部署中的安全.架构层的物理隔离.加密.证书的使用等等方面.推荐学习相关系统架构教程. 用户或者SQL的攻击注入时,怎么样做到安全? 很多英国的公司从安全的角度讲,做得很烂,因为团队不知道安全到底意味着什么.可能在网上随便问一些人到底该怎样做. 作为架构师要分析需求的话,并不是说做大型的前端设计,而是做一些

架构师速成6.6-知识的收集整理学习

知识如何学习前面已经讲了2节,这节主要讲知识的整理和沉淀. 其实我之前也一直没有好好的思考过这个问题,今天在整理自己的wiz知识库的时候突发灵感,所以有了这一节. 其实知识获取的过程分为搜索->收集->整理->精化->应用->分享,前一部分跟时间管理的收集也很相近吧.知识获取的思路适用于有目的的知识收集和日常的备忘性的知识收集.当然你随机收集一些资料记录下来其实效果并不是很理想,重要的是你要有目的的学习才能最大的发挥你的心智以及潜意识.当你主动要学习一项知识时,你的潜意识会主

架构师速成8.2-架构师要懂产品

产品和架构两个截然不同的职业,好像风马牛不相及,其实不是这样的.产品的思想需要经过技术的手来成为现实,在成为现实之前,需要技术理解.评估.碰撞.优化.把控.验证等等.当然架构师就承担了这一系列技术的责任,而且在一个产品的实现过程中,技术架构并不是很重要的,前期可以没有架构,简单快速验证,只有在用户多了之后,架构才有真正的用处.在初创公司,很多架构师都等不到用户多了的那一天,来实现自己的架构梦.所以产品这一关架构一定要把好,只有你把好了,后面才有机会让你去架构. 当然架构师的懂产品,是懂产品的生命

架构师速成8.3-架构师必须要了解的规则(转)

作为一个架构师,有些规则是必须要掌握的,这就想软件的公理,如果你学物理不知道牛顿定律,那就不要学了.在软件行业也有类似的东西,我称之为软件定律.例如: ACID,CAP,BASE ACID 传统数据库系统中,事务具有ACID 4个属性 (1)原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行. (2)一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态.这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性:事务