发信人: frankwong()
整理人: majorsun(1999-11-19 16:11:55), 站内信件
|
我个人认为,结合具体案例,多讨论些个人分析问题的角度,分析的方法,设计的模
型
对大家实际掌握分析理论,应用分析技术更有益.
如果仅仅讨论分析工具,分析软件是太局限了.
不知是否有人有兴趣讨论以下模型:
在一个数据驱动的案例中,如何建立其OO模型??
附:同样的问题在Rational OTUG中的一个回复:
If all you are doing is designing schemas for the individual
files, then all you need are straight ERD diagrams.
But I assume you are designing the engine that manages the
files. In particular, I assume this application needs to
know how to present the schemas (say to the user) and how to
transfer data between the files and a UI of some sort. In
effect this engine would be providing similar basic services
as something like MS Access provides to a user -- decoupling
from the mundane details of file I/O. Since you describe it
as a file management system, though, I assume you don't have
to deal with things like joins across files as you would in
an RDB.
Superficially a file management system is not very
complicated and there is a tendency to think that one simply
reads/writes through a buffer. For a very simple file
management system this might be true and there wouldn't need
to be a lot of OO modeling. In such a system you might have
a Record class with Read, Write, Lock, Release Lock, and
Check Locked methods.
But I think this is deceptive. For one thing, any multi
user lock management responsibilities probably want to be in
a separate object. If you are going to create new files,
then the File object has a life cycle associated with it
with significant responsibilities around creating and
storing schemas, mass record creation etc. The object that
manages your configuration file also probably has behavior
(e.g., to create File and Record Schema instances),
especially if schemas can be created or modified. If
schemas can be modified, then who handles conversion of the
existing data? Then, of course, if there is a GUI you have
plenty of opportunity to have Fun With Objects. I would
bet that as you identify the system's detailed functionality
that you find that there is plenty of behavior to spread
around.
Even if the system is fairly simple and there are not very
many active objects (i.e., objects with significant
behavior), that just makes the system easier to implement,
doesn't it? As opposed to making not be OO. [There are
situations like LALR(1) syntax translators and some pure
algorithmic problems that aren't suitable to OT, but in this
case I suspect it can be used effectively.]
BTW, I think your configuration file is a bit of a red
herring. I suspect that file simply provides persistence
for the data used to initialize the instances (e.g., Record
Schema) for the existing system. One thing to keep in mind
is that an application like this is at a higher level of
abstraction that fields in a schema. The only time you need
to know about the details of fields is when reading/writing
data from/to the record buffer -- and that will be almost
surely be completely contained in a single method. The
handling of schemas in the application is very likely to be
analogous to using C's printf function -- you provide a
string for the format and a data value but you don't really
care about the characters in the string because printf Just
Works.
Taking this to an extreme example, one could have a Record
Schema associated with each File and several Field Schemas
associated with each Record Schema. The Record Schema would
have the responsibility of providing field information in
order of field position. The Field Schema would have a
sequence number to identify its position in the record and a
string, initialized from the configuration file, that
described the format. The Field Write method of Record
would take a value, a field sequence number, and the string
from the appropriate Field Schema as arguments. At this
level of abstraction your application has no interest
whatsoever in the content of the format string; only the
Field Write method's implementation cares.
My point here is that this application seems to be concerned
with things like files and records and its behaviors should
reflect that. It should be data driven in the sense that it
relies on data from the configuration file to handle minor
variations like field formats while it carries out more
generic operations at a higher level of abstraction. So
long as those schemas are known only as strings in the
application, the application can handle arbitrarily complex
schemas. This is another example of what Mellor was
referring to awhile back by Modeling the Invariant.
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.101.101.78]
发信人: wangjianabc (jack), 信区: SystemAnalysis
标 题: Re: 多讨论些具体的分析方法比讨论分析工具更有意
发信站: 网易虚拟社区 (Wed Jun 23 11:33:41 1999), 转信
在Rational OTUG的回复中,集中表现出了系统分析以及设计中的关键问题:
1.系统的范围以及系统功能的确定:
在Rational OTUG的回复中集中讨论的是文件管理引擎的设计问题,因为他认为单
个文件的管理是很简单的.在实际的工作之中,应该以最简单的方式完成所需要的
功能,而其性能要求在功能要求之后, 否则你会发现自己的设计很难付诸实施.
对系统功能的确定,在此回复中采用的的是通过与MS Access进行类比的方法确定
的,这一方法广泛的应用在实际工作之中,可以少走弯路.如果对设计的新系统没有
可参照的样本,则必须采用对系统功能要求以及外部环境要求进行分析的方法予以
确认,难度是很大的.
2.系统构件的确定:
在此案例之中,由于是多用户文件管理的问题,所以对文件的读写操作,文件的创建
以及处理,临界资源的管理自然成为了此系统之中注重解决的问题.象这样标准的
操作系统问题,由于已经有了广泛的研究,解决起来可以采用标准的解法,面对这样
的解决方案再采用OOP的方法将其概念模型转化成系统的构件对象,如缓存区、i/
o接口、文件句柄等等，就可以完成系统初步设计。
当然要完成一个完整的设计，还要在这以设计的基础上进行改进和扩展，但这个
问题的确可以说明系统设计的初步理论以及方法。对于不同的设计人员来说，影
响其系统设计的关键应该是在于其选择的对问题的解法。
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.100.10.245]
发信人: hdejun (hdj), 信区: SystemAnalysis
标 题: Re: 多讨论些具体的分析方法比讨论分析工具更有意
发信站: 网易虚拟社区 (Thu Jun 24 19:52:28 1999), 站内信件
【 在 frankwong (frank) 的大作中提到: 】
: 我个人认为,结合具体案例,多讨论些个人分析问题的角度,分析的方法,设计的模
: 型
: 对大家实际掌握分析理论,应用分析技术更有益.
:
: .......
同意 !!.強烈呼吁各位同好能積极響應.因為大家的系統分析水平都不太高,
那我們
就從簡單的入手.議定一個題目共同討論.如有高手愿意指點,更是感激.
--
※ 来源:．月光软件站 http://www.moon-soft.com．[FROM: 202.98.109.186]
|
|