在阅读了关于4+1 Kruchten的文章之后,我需要使用这个概念来记录一个系统架构。我们决定使用UML代替Philippe提出的符号。我对process视图特别感兴趣,因为我不知道如何将它映射到我的流程中。我知道我可以使用维基百科和Sparx系统公司的论文建议的序列图或活动图。但它们没有提供有关图表本身的示例或细节。我已经在我正在为之开发的应用程序中确定了8个进程。这是否意味着我需要开发8个序列或活动图?我不认为将所有这些不同的过程压缩成这些图中的一个是合乎逻辑的。
其中一些程序的例子:
应该如何使用所建议的两个图中的任何一个来执行流程视图的实现?所识别的过程是合理的,还是过于抽象?例如,制作8个单独的图表或一个覆盖所有过程的图表是否明智和清晰?
发布于 2016-06-25 16:20:04
回答这些问题对我来说是有意义的:
所识别的过程是合理的,还是过于抽象?
您的流程列表中的项目相当简短,在我看来更像是场景标题名称,而不是进程。正如我所读到的,在4+1中,进程本质上是在运行程序。
..。在最高层,流程体系结构可以看作是一组独立执行的通信程序逻辑网络(称为“进程”). 4+1视图-架构。
process视图是程序之间交互的分解(大概是在完成一个场景时)。它可能需要几个相同类型和不同类型的图表。
因此,您需要识别正在交互以完成方案的各个进程(例如程序)。
这是否意味着我需要开发8个序列或活动图?例如,制作8个单独的图表或一个覆盖所有过程的图表是否明智和清晰?
不一定。您很可能需要一个以上的图表;然而,您很多人并不需要精确的8个图表。在确定了交互的程序(对于每个场景)之后,您可能会发现它们中有几个在两个或多个场景之间进行协作。例如,您可能会发现您可以在单个进程视图图(客户端程序和多个服务器程序之间的交互)上一起显示帐户查找和身份验证。
让我们举一个最简单的例子:您有两个进程(程序)A和B。要显示它们之间的交互,可以使用单个进程视图图(可能是序列图,但也可以使用通信或其他)。因此,如果你愿意的话,两个相互作用的过程会产生一个图表。
应该如何使用所建议的两个图中的任何一个来执行流程视图的实现?
首先,正如前面提到的,关键是识别正在交互的进程(程序),然后使用图表创建流程视图(S),以显示那些交互的过程(对于给定的场景)。我建议从通信图开始,因为这些关系图允许以易于阅读的方式显示组件之间的交互。如果需要显示单个交互的顺序,则使用序列图。活动图应保存为后续的详细信息。首先,活动图没有指出业务逻辑各个步骤(决策等)的交互过程中的"who“部分,而且在流程视图中,至少在更高的层次上,您试图显示交互的”谁“。
..。通信图显示每个元素与更好的交互,而序列图则更清楚地显示交互的顺序。. 沟通图维基百科
当您识别交互组件时,请记住谁对什么信息负责或权威。在4+1中,似乎没有多少对信息模型的道义支持,我认为信息模型是系统体系结构描述的一个关键组成部分,在高层次上可以理解为谁对哪些内容具有权威性和负责(在较低级别可以或多或少地以关系的方式阐述)。例如,在订单系统中,负责接收订单的组件与发出订单id号的组件相同,它们存储订单以供以后检索,而后者则属于系统的信息模型和信息责任方面。
就我个人而言,我喜欢领域驱动设计,而且我还添加了对生态系统中角色的更高层次的描述。(虽然我也(不得不)使用了TOGAF,但我觉得这并不是最好的,但至少比4+1 ( IMHO)更现代)。
https://softwareengineering.stackexchange.com/questions/323249
复制相似问题