📄 lab2_1.md~
字号:
origin_y 0
items (list diagram_item_list
(object CategoryView "Use Case View::Use-Case Model" @46
location (384, 880)
font (object Font
size 10
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
Parent_View @46
location (189, 779)
fill_color 13434879
nlines 2
max_width 390
justify 0
label "Use-Case Model")
icon_style "Icon"
line_color 3342489
fill_color 13434879
quidu "35B677F4010E"
width 402
height 215)
(object NoteView @47
location (1040, 560)
font (object Font
size 10
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
Parent_View @47
location (813, 358)
fill_color 13434879
nlines 9
max_width 419
label "The Use-Case Model is traceable to (and derives from) the Business Model. The system (as described in the Use Case Model) provides behavior that supports the business.")
line_color 3342489
fill_color 13434879
width 479
height 416)
(object CategoryView "Use Case View::Business Use-Case Model" @48
location (384, 320)
font (object Font
size 9
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
Parent_View @48
location (189, 229)
fill_color 13434879
nlines 2
max_width 390
justify 0
label "Business Use-Case Model")
icon_style "Icon"
line_color 3342489
fill_color 13434879
quidu "35B677D701B8"
width 403
height 194)
(object ImportView "" @49
stereotype TRUE
line_color 3342489
quidu "35C633DA030C"
client @46
supplier @48
line_style 0)
(object AttachView "" @50
stereotype TRUE
line_color 3342489
client @49
supplier @47
line_style 0)))))
root_category (object Class_Category "Logical View"
quid "34DBB4830141"
documentation
|Rational Unified Process uses the "Logical View in Rose" to organize the Design Model and the Process View and the optional Business Object Model and Analysis Model.
exportControl "Public"
global TRUE
subsystem "Component View"
quidu "34DBB4830143"
logical_models (list unit_reference_list
(object Class_Category "Business Object Model"
quid "35B678080064"
documentation
|This model is optional.
|The Business Object Model contains a set of interacting workers and business entity (domain) classes which collaborate to enact the business processes. In some cases, only the business entity classes are documented. The business entity classes as a whole are sometimes referred to as a 'domain model'.
|
|The business modeling workflow in Rational Unified Process produces two models: the business use-case model, and the business object model. Both show the business
|processes, but different aspects of them. In the business use-case model each business use case represents a business process, described (text and/or activity diagrams) from an "external" view point without worrying about who does what to whom inside of the organization.
|In the business object model, you include realizations of each business use case to show how workers and entities collaborate to perform the process. You do that using class diagrams, activity diagrams with swimlanes, collaboration diagrams, and/or interaction diagrams.
|
exportControl "Public"
logical_models (list unit_reference_list)
logical_presentations (list unit_reference_list))
(object Class_Category "Analysis Model"
quid "35B678170028"
documentation
|This model is optional.
|The Analysis Model contains a set of Analysis Classes, which describe an abstract realization of the use cases of the system. The analysis classes evolve into associated design elements which are modeled in the Design Model.
exportControl "Public"
logical_models (list unit_reference_list)
logical_presentations (list unit_reference_list))
(object Class_Category "Design Model"
quid "35B6782302DA"
documentation
|The Design Model in Rational Unified Process.
|The design model is adapted to model the real implementation environment, and serves as an abstraction of the source code. It is a "blueprint" of how the source code is structured and written.
|
|The design model is a hierarchy of packages (design subsystems and design-service packages), with "leaves" that are classes. Subsystems are a design "view" of the components that are defined in the Implementation Model.
|
|The design model hierarchy consists of layers.
|
|Classes represent abstractions of classes in the system's implementation. They define the objects, which in turn are abstractions of the objects in the system's implementation. The use cases are realized by the objects, and this is represented by use-case realizations in the Design Model. Each use-case realization has a realize dependency to a use case in the Use-Case Model.
exportControl "Public"
logical_models (list unit_reference_list
(object Class_Category "Use-Case Realizations"
quid "34E36D3203CA"
documentation
|In this Package we will describe "Use Case Realizations" as stereotyped use cases.
|
|A use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects.
|
|A realize dependency is used between the "Use Case Realization" and the "Use Case" in the use-case model that is realized.
|
|
exportControl "Public"
logical_models (list unit_reference_list)
logical_presentations (list unit_reference_list))
(object Class_Category "Process View"
quid "35D227B103C0"
documentation "An architectural view that describes the concurrent aspect of the system: tasks (processes) and their interactions."
exportControl "Public"
logical_models (list unit_reference_list
(object Class "<Process Name>"
quid "35DB3C8302D0"
documentation "This process provides <enter a description here of what the role of the process in the system is>. A separate process was chosen for this to be able to <enter the rationale for needing a separate process>."
stereotype "process")
(object Class "<Thread Name>"
quid "35DB3CB002BC"
documentation "This is a sub-process or thread within the <name of process of which this thread is a sub-process> process which handles <enter a description of what this thread does>. A separate thread was chosen for this to be able to <enter the rationale for creating a separate thread>."
stereotype "thread")
(object Association "$UNNAMED$45"
quid "35DB3E72017C"
roles (list role_list
(object Role "$UNNAMED$46"
quid "35DB3E73005A"
supplier "Logical View::Design Model::Process View::<Process Name>"
quidu "35DB3C8302D0"
is_navigable TRUE
is_aggregate TRUE)
(object Role "$UNNAMED$47"
quid "35DB3E730096"
supplier "Logical View::Design Model::Process View::<Thread Name>"
quidu "35DB3CB002BC"
Containment "By Value"
is_navigable TRUE))))
logical_presentations (list unit_reference_list
(object ClassDiagram "Process View"
quid "35DB3C2A02B2"
title "Process View"
documentation "This diagram illustrates the composition of processes and threads, and the mapping of classes onto those processes and threads."
zoom 100
max_height 28350
max_width 21600
origin_x 0
origin_y 0
items (list diagram_item_list
(object ClassView "Class" "Logical View::Design Model::Process View::<Process Name>" @51
ShowCompartmentStereotypes TRUE
IncludeAttribute TRUE
IncludeOperation TRUE
location (288, 464)
font (object Font
size 9
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
Parent_View @51
location (122, 436)
fill_color 13434879
nlines 1
max_width 332
justify 0
label "<Process Name>")
stereotype (object ItemLabel
Parent_View @51
location (122, 389)
fill_color 13434879
anchor 10
nlines 1
max_width 332
justify 0
label "<<process>>")
icon_style "Icon"
line_color 3342489
fill_color 13434879
quidu "35DB3C8302D0"
width 350
height 172
annotation 8
autoResize TRUE)
(object ClassView "Class" "Logical View::Design Model::Process View::<Thread Name>" @52
ShowCompartmentStereotypes TRUE
IncludeAttribute TRUE
IncludeOperation TRUE
location (896, 464)
font (object Font
size 9
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
Parent_View @52
location (740, 436)
fill_color 13434879
nlines 1
max_width 312
justify 0
label "<Thread Name>")
stereotype (object ItemLabel
Parent_View @52
location (740, 389)
fill_color 13434879
anchor 10
nlines 1
max_width 312
justify 0
label "<<thread>>")
icon_style "Icon"
line_color 3342489
fill_color 13434879
quidu "35DB3CB002BC"
width 330
height 172
annotation 8
autoResize TRUE)
(object AssociationViewNew "$UNNAMED$45" @53
location (596, 464)
stereotype FALSE
line_color 3342489
quidu "35DB3E72017C"
roleview_list (list RoleViews
(object RoleView "$UNNAMED$46" @54
Parent_View @53
location (-300, 0)
stereotype FALSE
line_color 3342489
quidu "35DB3E73005A"
client @53
supplier @51
line_style 0)
(object RoleView "$UNNAMED$47" @55
Parent_View @53
location (-300, 0)
stereotype FALSE
line_color 3342489
quidu "35DB3E730096"
client @53
supplier @52
line_style 0))))))))
logical_presentations (list unit_reference_list)))
logical_presentations (list unit_reference_list
(object ClassDiagram "Welcome"
quid "3512226B0028"
title "Welcome"
documentation
|Welcome to the Rational Unified Process Frame Work
|
|Purpose of the FrameWork:
|a) provide a good structure for a Rose model
|b) provide a style guide with naming conventions/suggestions
|c) identify a minimal set of diagrams to produce
|d) relate activities in RUP to Rose diagrams
|e) provide a basis for sophisticated SoDA reports. For instance based on this structure most of the Rose parts of the "Software Architecture Document" are generated from SoDA.
|
zoom 100
max_height 28350
max_width 21600
origin_x 0
origin_y 0
items (list diagram_item_list))))
root_subsystem (object SubSystem "Component View"
quid "34DBB4830143"
documentation
|In Rational Unified Process the "Component View in Rose" is used to organize the implemetation model.
|
|The Implementaition View in Rational Unified Process
|
|
physical_models (list unit_reference_list
(object SubSystem "Implementation Model"
quid "35B67C9A0348"
documentation
|The Implementation Model in Rational Unified Process is a collection of components, and the implementation subsystems that contain them.
|
|An architectural view that describes one or several system configurations; the mapping of software components (tasks, modules) to the computing nodes in these configurations.
|
|Defines, executables, dll's, files, subsystems, compilation order etc.
|
|Rational Unified Process:
|Activity: Define the Organization of Subsystems
|
|These diagram will be presented in the Implementation View section in the document generated using the SoDA Software Architecture Document.
|
|It is recommended that, in most cases, the mapping should be
|1:1 between design and implementation, that is, for each package in design there is one subsystem in the implementation model.
|
physical_models (list unit_reference_list)
physical_presentations (list unit_reference_list
(object Module_Diagram "Implementation Model Structure"
quid "34DBB487006E"
title "Implementation Model Structure"
documentation "This diagram presents the organization of the Implementation Model."
zoom 100
max_height 28350
max_width 21600
origin_x 0
origin_y 0
items (list diagram_item_list
(object NoteView @56
location (624, 160)
font (object Font
size 9
face "Arial"
bold FALSE
italics FALSE
underline FALSE
strike FALSE
color 0
default_color TRUE)
label (object ItemLabel
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -