祝大家 新世紀快樂!!
--
[m※ Origin: 雲林科技大學藍天使 <bbs.yuntech.edu.tw> [From: 140.125.243.145]
1. The answer depends on the platform (O.S.) The general difference
many people referring is PROCESS has its own (O.S allocates for it)
computation space, and THREAD shares this space with THREADS
within the same PROCESS. However, it is not always valid for some
systems. Regrading the "THREAD of control" in the UML, it can be a
PROCESS, a thread, or simply a sequence of interactions.
2. and 3.
Diagrams depict knowledge in a communicable form. Reference [1] organizes
the following UML diagrams around architectural views regarding models of
problems and solutions:
1. The User Model View, also known as the “Use Case View” or
“Scenario view”:
(1) Use case diagrams depict the functionality of a system of this
view.
2. The Structural Model View, also known as the “Logical View” or
“Static View”:
(1) Class diagrams depict the static structure of a system.
(2) Object diagrams depict the static structure of a system at a
particular time.
3. The Behavioral Model View, also known as the “Dynamic View”,
“Process View”, “Concurrent View”, or “Collaborative view”:
(1) Sequence diagrams depict an interaction among elements of a system
organized in time sequence.
(2) Collaboration diagrams depict an interaction among elements of a
system and their relationships organized in time and space.
(3) Statechart diagrams depict the status conditions and responses of
elements of a system.
(4) Activity diagrams depict the activities of elements of a system.
4. The Implementation Model View, also known as the “Component
View” or “Development View”:
(1) Component diagrams depict the organization of elements realizing a
system.
5. The Environment Model View, also known as the “Deployment
View” or “Physical View”:
(1) Deployment diagrams depict the configuration of environment
elements and the mapping of elements realizing a system onto them.
[1] S. Alhir, “Understanding the Unified Modeling
Language (UML),” Newsletter of Methods & Tools, Martinig & Associates,
April 1999.
不知在台灣的各位朋友們, 有哪家公司在開發系統
時, 會努力去畫4+1view, 用力的討論你們的系統
架構/
柯仁傑
※ 引述《ct...@cat.syr.edu (Cheng-jan Tang)》之銘言:
--
[1;32m※ Origin: [33m交大資工鳳凰城資訊站 [37m<bbs.csie.nctu.edu.tw> [m
[1;31m◆ From: [36m249.c150.ethome.net.tw [m
This question is too general to be answered. :)
In fact, I would say "No." At least, no group I known of
has been doing this consistently, which includes Rational. :)
Usually, the 4+1 views have (can) to be tied up with a
development process, i.e. RUP, XP, Waterfall, Booch,
OOSE, OOT, ROOM, Catalysis, ... just to name a few.
And the "stakeholders" as well as the "supporting tools"
affect the usage and necessaity of a partivular view.
For example, you cannot "DRAW" a process view in the
visual modeler, which is also developed by Rational.
> 還是會以其他不同的東西來表示?
There are many different software delievery/process
standard/methods. The most common use one is still
"natural language." :) And based on different purpose
, a different methodolgy might be applied. Like
DFD/CFD, FSMs, REVS, PN, CPN, DTs, PDL, RLP,
SDL are some popular approaches.
P.S. The biggest difference here and Taiwan is:
Customers have their own rules, formats, and
requirements, which are following or extending
some mature standards. It seems difficult for a
developer to follow or understand so many
different standards, but it also reduces a lot of
misunderstandings and ambiguity. It eventually
makes everybody's life much easier.