分析模型——开发者的视野
在系统分析的过程中，我们所关注的依然是问题，但是，同用例模型不同的是，用例模型是从最终用户的角度来看待问题，而分析模型是从开发者的角度来描述问题。用例模型的主要工作是描述现实世界的业务流程，而很少会涉及系统的概念。分析，则是从系统的角度来来看待软件应该为用户提供的服务。同样，同设计不同的是，分析仍然停留在“做什么"的层次。而设计，则需要解决“怎么做的问题”。
开发语言等技术选择通常不会在分析模型中考虑。分析模型是独立于实现的，这样，可以提供最大的复用，并且，可以帮助开发人员防止过早的陷入技术的细节中去，从而能够从一个更加一般的角度去理清思路。进行分析建模的第一步，通常是识别对象，然后提取出类。考虑著名的MVC模式，我们需要识别实体、控制和边界三种对象。按照MVC模式来为识别对象做指导，是非常好的做法。对象识别的结果，就是我们所需要的静态模型，通常表现为类图。
我们首先识别出实体对象，这些对象通常来说是比较明显的，例如系统中的角色，系统需要处理的资料，如本系统中需要计算的生产指标等。然后我们需要识别为了完成系统业务逻辑而需要的业务逻辑对象，以及同用户进行交互的界面类，在MVC模式中，他们分别对应于控制类(Contr01)和边界类(View)。在分析阶段，这些对象通常都按照比较自然的方式来组织，例如，为了完成一个业务功能，我们通常需要一个控制类和一个边界类，控制类执行业务逻辑，边界类同客户进行交互。
MVC体系结构中的控制层主要负责控制应用系统中的逻辑流程并为模型层和视图层之间提供联系，即执行模型层的程序逻辑以作为用户请求的响应，并选择下一个可以显示的视图。换句话说，控制层将业务数据和其显示逻辑有效地分离开来。
在应用系统中，控制层可以实现客户模块、Web模块、EJB模块或是它们中的相应组合。一个只处理视图的用户端通常被认为是瘦客户(thin client)，而胖客户(fat client)则可以实现视图和控制层。
通常一个Web层的控制器可以处理来自客户的HTTP请求，并将这些请求传送给EJB层的控制器，而后者就可以激活相应程序逻辑的处理。Web层控制器同时还可以为Web瘦用客户选择用于显示的视图组件。
在Visual Factory系统中，我们在Web模块和EJB模块中实现了控制器的功能，也就是使得其作用于模块之间。系统中的控制器可以接受和处理在Web层和EJB层之间的请求，同时我们在其中也采用了一定的设计模式，即命令模式。例如一个由Java Servlet实现的Web层的控制器可以接受基于HTTP的请求，并根据Web层提供的接口而执行相关的功能函数。所有用户的请求都将通过这个前端的控制器，而后者则会基于请求中的数据和请求的类型，并将其转化为相应的事件对象(event object)。之后该控制器会将所生成的事件传送给EJB层的控制器，后者通常由会话bean实现，它将所接收到的事件映射为相应的命令，最．后该命令会激活会话层面的操作，从而实现所需的程序逻辑。
前端的控制器通常都是一个很有效的设计方法，因为它可以为所有对于应用系统的请求提供一个单一的访问接口，即解释请求，执行程序逻辑，处理安全和异常，并选择合适的视图。一般来说，这种应用系统中的核心控制也会使得实现应用服务更加容易。
实现这样一个基于命令模式的控制器，不仅可以简化会话层面的实现，同时可以使得控制器的实现更为清楚整洁。
在Visual Factory系统的体系结构中，大部分的组件都可以归于模型层、视图层或是控制层。控制层的组件多数处理用户的请求，包括接受用户请求并提供相应的反馈，例如Web层和EJB层的控制器，以及请求处理器。模型层的组件主要处理程逻辑，如各种数据对象、会话管理模块等。它们主要是根据用户的请求而提取和整理相应的数据。视图层的组件负责将计算后产生的统计图形显示出来。
Pareto Chart：排列图又称为柏拉图，是质量管理分析和寻找影响质量主原因素的一种工具，其形式用直角坐标图，纵坐标表示频率(如百分比表示)横坐标表示影响质量的各项因素，按影响程度的大小(即出现频数多少)排列。
·DPMO：为Defects Per Million Opportunity的缩写。指1 00万个机会里面，出现缺陷的机会是多少。这里有一个计算公式，即DPMO=(装配期间产生的缺陷总数X 106)÷(缺陷机会总数) 。
数据库核心设计
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
