软件设计

UML是什么 Unified Modeling Language (UML)又称统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。 面向对象的分析与设计(OOA&D，OOAD)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。 UML有什么 UML 2.4.1 发展了已经获得成功的 UML 2.0规范 ，并迅速成为建立软件系统可视化、规范、文档的标准。统一建模语言(UML) 也被用于非软件系统的建模，并在很多领域，诸如金融，军事，工程方面应用广泛。 UML 2 定义了13种基本的图，它们被分成两大类: 1. 结构建模图 结构图定义了一个模型的静态架构。它们通常被用来对那些构成模型的‘要素'建模，诸如：类，对象，接口和物理组件。另外，它们也被用来对元素间关联和依赖关系进行建模。 2. 行为建模图 行为图用来记录在一个模型内部，随时间的变化，模型执行的交互变化和瞬间的状态；并跟踪系统在真实环境下如何表现，以及观察系统对一个操作或事件的反应，以及它的结果。 UML可以用来做什么 嵌入式软件分析设计

软件工程与UML笔记 第一章 面向对象软件工程概论 要求学习的内容： 软件危机 软件工程的由来 软件工程的定义 软件工程的范畴 软件工程实践的目标 软件开发包含的活动 软件维护的成本 修复bug的代价 一.软件危机 软件定义： 软件是程序以及开发、使用和维护程序所需要的所有文档。 软件危机定义： 软件开发和维护过程中遇到的一系列严重问题 表现： 对软件开发成本和进度的估计不准确； 软件产品质量很不可靠； 可维护性差，软件的文档资料不完整和不合格； 软件成本逐年上升； 软件开发生产率不高，不能满足客观需要。 软件危机原因： （1）人们对于软件概念与范畴的理解。 早期软件工程师崇尚个人英雄主义，整个软件开发通常处于一种无序的状态。他们大多认为编写程序就是软件开发的全部。这种观念会导致随着软件规模的增大，程序员对于文档的忽略与不重视，使得软件开发产品的不健全与维护困难。 （2）软件的规模日益增长、设计日益复杂。 Visual Studio/Office等（M->G） （3）软件开发组织发生变化。 在上述因素发生变化的同时，软件开发组织也在发生着变化。早期开发一款小型软件，可能1-2个开发人员就可以完成。然而随着软件规模的飞速增长，软件开发组织也在同比例增长，由单打独斗的状态改变为一个团队若干开发人员共同研发一款产品。人员由一个变成团队协同开发，这种组织形式的转变

　　用户界面评审特别是那些非正式的评审可以简单而直接地引入到几乎任何软件开发环境或过程中,所需要做的就是鼓励设计人员和程序员将其工作展示给同事来征求评论和建议。评审方法通常会促进协作,即使是最没有效的评审过程也会有利于开发人员之间交流思想和共享信息。用1-2小时时间来审视一些屏幕画面可以给用户界面带来很大改进。同行评审的最大问题是容易陷于长时间毫无结果的争论。非正式的同行评审特别是在没有很好加以计划和组织的情况下可能会导致比较低的效率,但其成本相对也较低。同行评审的质量可能还会受到同行经验的很大制约。成功的关键在于让那些有经验的开发人员参加评审,并且事先为有效发现可用性问题对评审活动加以认真计划和组织。 　　用户界面设计、可用性工程和人机交互方面的专家已经成为软件领域的重要技术资源。可用性专家可以为我们提供现成的技能和知识,而不必我们自己费力去学习。但是,现在还没有足够数量的合格专家来满足世界上所有软件开发项目的需要。即使是在适合的情况下依靠专家来解决可用性问题,开发人员自己无能为力的状况仍然得不到改变。在许多情况下,开发人员并没有真正理解这些来自专家的技能或知识。 　　软件开发过程一直都在不停地发生着变化，这种变化几乎发生在所有方面。编码曾经一度意味着个人埋头苦干,而如今已经成为一种团队过程。 　　近年来,软件和计算机应用系统开发的社会经济环境发生了巨大的变化

设计模式—UML类图 欢迎关注笔者的微信公众号 UML UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。 UML 2.2中一共定义了14种图示。为方便了解，可分类成右侧的结构。 结构性图形（ Structure diagrams ）强调的是系统式的建模： 静态图（static diagram） 类图 对象图 包图 实现图（implementation diagram） 组件图 部署图 剖面图 复合结构图 行为式图形（ Behavior diagrams ）强调系统模型中触发的事件： 活动图 状态图 用例图 交互性图形（ Interaction diagrams ），属于行为图形的子集合，强调系统模型中的资料流程： 通信图 交互概述图（UML 2.0） 时序图（UML 2.0） 时间图（UML 2.0） 类图 类图是什么？ 用于描述系统中的类(对象)本身的组成和类(对象)之间的各种静态关系。 类图的表示 + 公共 public - 私有 private # 保护（即对子类可见）protected ~ 包（对包内其他成员可见） / 推导（即由其他属性推导得出，不需要直接给定其值） 例如：有一个 Person 类

在没有好好地研习面向对象 设计 的设计模式之前，我对Java接口和Java抽象类的认识还是很模糊，很不可理解。 刚学Java语言时，就很难理解为什么要有接口这个概念，虽说是可以实现所谓的多继承，可一个只有方法名，没有方法体的东西，我实现它又有什么用呢？我从它那什么也得不到，除了一些方法名，我直接在具体类里加入这些方法不就行了吗？ 为什么一定要有抽象类这个概念？为什么就不能把这个父类写成一个具体的类，子类再继承它不就可以了吗？何必弄一个抽象类出来，还要弄一些没有方法体的抽象方法，弄得又象接口又象类的，让人捉摸不定。 当我开始 学习 java设计模式，真正走进面向对象设计的大门之后，我才发现，自己对面向对象设计的理解原来是那么的片面，那么的肤浅，根本就没有真正理解面向对象思想的精髓，在某一种程度上还受着面向过程的影响，以为弄出了一个个类，就算是面向对象了，而其实还是被过程所驱使着。 我还是说说我现在对面向对象思想的理解吧，不一定正确全面，但我想应该还算是比以前略有进步吧。 面向对象思想，我觉得最关键的就是抽象。 一个软件设计的好坏，我想很大程度上取决于它的整体架构，而这个整体架构其实就是你对整个宏观商业业务的抽象框架，当代表业务逻辑的高层抽象层结构 合理时，你底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时

　　怎样才能满足对可用性日益增长的需求?软件可用性可以通过许多途径加以改进,但人们普遍使用的是其中几种比较成熟的方法。最受人们欢迎和广泛使用的方法有可用性测试、风格指南及标准、专家咨询和反复原型设计。尽管这些方法往往是有效的,但它们都有很大的不足。 　　改进软件可用性方面最常用的方法是可用性测试。可用性测试是以人们熟悉和广泛传授的标准技术为基础的。测试可以在可用性测试实验室中在受控条件下进行,或者是在日常工作条件下通过现场测试来进行。可用性测试的实验室方法和现场方法各有长处和不足,在时间和预算允许的情况下,最好结合在一起使用。如果运用得当,实验室和现场可用性测试方法都会成为改进软件可用性的有效手段，但它们都有各自的严重局限。可用性测试是一种改进软件可用性的有效手段，但高质量不是靠测试得到的。所有测试技术的最大问题是它们往往是在产品开发过程后期才进行。要进行测试，必须要有一个东西可以测试，通常这要求已经有一个正在开发的可以使用的系统、一个相对完整的模拟系统或者能够充分运转的原型。发现和改正任何软件缺陷的成本是随时间增加的。一旦系统交付使用,发现和改正缺陷的成本将会大幅度增加。为了改进质量，通过更有效地运用更好的方法去防止缺陷远比缺陷检测和清除更加高效和划算。 　　可用性测试经常避免不了这样一种情况 ，即无论测试如何细致入微和富有成果，其结果往往不尽如人意。对于开发过程来说

1.建模 1.1 为什么要建模 建立大厦和建立狗窝的区别是建设狗窝不需要设计。要生产合格的软件就要有一套关于体系结构、过程和工具的规范。 建模的定义：建模是对现实的简化。 建模的目标： 1）模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。 2）模型允许我们详细说明系统的结构和行为。 3）模型给出一个知道我们构造系统的模板。 4）模型对我们的决策进行文档化。 建模就是把复杂的系统变成小的系统，采用“各个击破”的原则逐一解决。 1.2 建模原理 1）选择创建什么模型很重要，模型要反映你难于处理的开发问题。 2）模型要在不同的精度级别上来表示。你可以根据观察的角色和观察的原因来选择精度。 3）建造模型要和现实相连。 4）重要的系统需要用一组独立的模型去处理。在面向对象的软件体系中，为了理解系统的体系结构，你需要几个互补和连锁的视图：用例图、设计视图、进程视图、实现视图和实施视图。 1.3 面向对象的建模 面向算法的建模在需求发生变化或者系统增长后就变得难以维护。 面向对象的建模把对象和类作为其主要构造块。例如，在三层结构中，我们可以在用户接口层、中间层和数据库层中找到你想要的对象。 2 UML介绍 2.1 概述 UML可以对软件密集型系统的制品进行可视化、详述、构造和文档化。最好把它用于以用况（用例）为驱动、以体系结构为中心、跌代及增量的过程中。 UML是一种语言

软件架构设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述了解软件架构的含义和怎样设计软件架构。 软件架构师的职责 架构师分为以下几大类：业务架构师、主题领域架构师、技术架构师、项目架构师（J2EE架构师、.NET架构师等）、系统架构师。 1、 架构师 的职责主要体现 架构师的职责就是设计一个公司系统的基础架构，并提供关于怎样建立和维护系统的指导方针。具体来讲，架构师的职责主要体现在以下几方面： 1）、负责公司系统的架构设计、研发工作。 2）、承担从业务向技术转换的桥梁作用。 3）、协助项目经理制定项目计划和控制项目进度。 4）、负责辅助并指导系统分析开展设计工作。 5）、负责组织技术研究和攻关工作。 6）、负责组织和管理公司内部的技术培训工作。 7）、负责组织及带领公司内部员工研究与项目相关的新技术。 8）、管理技术支撑团队并给项目、产品开发实施团队提供技术保障。 9）、理解系统的业务需求，制定系统的整体框架（包括、技术框架和业务框架）。 10）、对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。 2、 构架设计师 必须具备的技能 经验：既包括在问题领域的经验（通过彻底了解需求）

1、什么是UML？ 统一建模语言UML是OMG（Object Management Group）在1997年发表的图标式软件设计语言，它综合了多种当时已经存在的面向对象的建模语言、方法和过程。 2、特点： 对于一个软件系统而言，UML具有以下的重要功能：可视化功能、说明功能、建造功能和建文档功能。 2.1：可视化功能 可视化功能可以促进对问题的理解和解决，并且方便我们熟悉UML语言的设计师之间彼此的交流和沟通。 可以较容易的发现设计草图中可能的逻辑错误，保证最后完成的软件确实能按照要求运行，避免和减少错误。 2.2：说明功能 对于一个系统的说明应当通过一种通用的、精确的、没有歧义的通信机制进行，显然，UML特性使得UML很适合这种说明工作。 系统的整体设计可以指导软件的开发过程。由于重要的决定均可以在开始写代码之前就做出，因此可以减少底质量的代码，进一步降低开发成本。 2.3：建造功能 UML有它自己的开发规则，这使得人们可以通过建模软件对一个系统设计模型加以解释，并将设计模型映射到一种计算机语言上。这也就是说，使用一种建模工具可以大大加快建模和系统设计的过程。 可以通过UML可以看到总体的图像，这样一来可以均衡调配系统所消耗的资源，使系统更有效率。因为系统设计的首先完成，所以很容易就能发现可以复用的代码。代码能够高效率地实现复用，可以降低开发成本。 2.4、建文档功能

　　在设计过程中，我们的重点要放在可以很快掌握和应用的那些简单而有效的技术上。例如，有一位擅长Web应用的自由设计师，在通过一次简短的会议演讲学习了以使用为中心的设计方法后，马上将其用到自己的工作中。还有一位计算机外部设备公司的项目经理，在参加了一次一小时的讲座后，就向其项目团队成员介绍如何使用用例模型来改进软件的用户界面。在全世界，成功运用这种开发方法的公司遍布于银行应用系统、工业自动控制以及商用软件开发工具等各个领域。 　　使用模型作为一种杠杆，来帮助解决用户界面设计中的问题。用简单的模型来帮助认识问题和找到解决方案，通常可以提高效率，但对许多新手来说，刚刚接触时可能会感到有一些困难。引发人们兴趣的研究问题与现实生活中进行的日常决策是不同的。学术界和专业人员似乎通常认为，只有通过认知和感知心理学才能认识和理解人机交互，要想很好地进行人机交互设计，必须首先阅读大量的学术文献。 　　创造欲望是优秀设计的基本元素。某些将用户界面看成是一种戏剧艺术或认为设计主要基于艺术灵感的专业人员，一直对以使用为中心设计方法的系统化本质持反对态度。而从另一个方面来看，在我们这些积极拥护基于模型的方法的人当中，有许多设计和艺术专业人员，他们认识到，抽象模型可以激发更大的创造力。 来源： https://www.cnblogs.com/dgb152/p/12253765.html