如何提高我的软件分析和UML技能

时间：2014-11-08 12:20:51

标签： uml software-design

我正在开发一个开源项目，该项目展示了如何使用测试驱动开发和域驱动设计的一些想法迭代地开发软件。我知道我会做什么，但是我的正式技能（特别是关于UML）有点生疏。

下面我将发布我的第一步图表和我将给读者的解释。

我有以下问题：

  1. 最后一步以问题But what will stich together these components?结束。如何以UML术语向读者展示方式，而不是在思路中跳过任何东西？我打算做的是让每个组件提供Environment类。出于测试目的，TestingEnvironment将收集所有这些环境并将正确的回调注入World。但是，使用哪种类型的UML图来显示我的思路，以及以何种顺序？ 我的问题是，不知何故，我知道我想做什么，但我不能让自己理性化为什么我想这样做 - 我想它已经成为我的一部分我不再有意识地做出这样的决定。
  2. 到目前为止我犯了什么错误，如何修复它们，最重要的是：为什么？

    3. 第1步

    0001_user_commands_use_cases.pdf （0001_user_commands_use_cases.pdf）

    0002_user_commands_use_cases.pdf （0002_user_commands_use_cases.pdf）

    User Use Cases - Analysis

We are starting with an use case diagram (0001_user_commands_use_cases.pdf) as
part of the preliminary analysis stage. This diagram should only help us
understand what our client wants. These use cases may change over time, but
never the less, they help us understand the system we are going to develop.

Please follow the arrows while reading the following explanations.

The role the user plays when interacting first with our system will be Guest.
The Guest sends to the system some registration data, which we process.

In the diagram, we are describing what happens from a logistic point of view,
from the perspective of the client for which we write the application. We are
not referring yet to classes or objects, or the concrete workflow, which may
end up being quite different.

We are also not dealing with errors, because that would only add more
background noise to the idea - and because error handling does not add business
value to the system. Of course, a system has to be robust to errors, but keep
in mind that we're now just making the analysis - not the design of the system.

Logistically speaking, after the Guest has sent us the registration data, there
is a Registered User. A registered user can send us the login data, so that he
becomes an Authenticated User.

Following the diagram, we can see how only an Authenticated User can send to us
a request to log out of the system, thus becoming a Deauthenticated User.

Why a Deauthenticated User, and not a Guest back again? Basically, it comes
down to us not being able to foresee the future. We really have no idea how the
client will want us to extend the system - nor does he himself! Beside that,
the two roles, a Guest which we know nothing about, and a user which has just
deauthenticated, which we do know something about, are really different things.

Of course it may be that the Deauthenticated User will exist in our application
only for a very short period of time, or it may be that it's created for the
sole purpose of being destroyed back again, without being looked at by any
other subsystem of our ERP - but still I cannot stress it enough: logistically,
the role of a Deauthenticated User stands on its own.

The second diagram (0002_user_commands_use_cases.pdf) contains all the
information of the first diagram, with some added items. If you follow the
green arrows, you will see that the process is the same.

In the first diagram we notice how all three things done by the ERP system are
some kind of generalizations of a process. We have introduced this new generic
process in the second diagram as "Process Data".

Another element we have added in the second diagram is a generalization of the
three "Sending Data" elements. We are not sure how this will materialize in the
next stage (designing the system), but it looks like there's a generalization
there which may, in the end, make the system easier to maintain and extend.

We always seek new generalizations and abstractions because they have this nice
property of making the code maintainable and extendable.

Conclusion
----------

In our design, the ERP will do one central thing, "Process Data", data which
will come in in a standardized way, represented in our second diagram by the
"Send Data" use case.

We don't know how we will design these things yet, until now we have only
thought about the logistics, since we are doing just the analysis.

In the next commit, we are going to look closer at the application domain, in
order to better see the relations between all these notions and to enable us to
come up with a cohesive design.

    第2步

    enter image description here 

    A rough overview of the components in the context of the application domain

Before looking at the diagram, let me first explain the thoughts I had prior to
coming up with this diagram.

We are going to design an ERP. What is this all about, and where lies the
business value in it?

We are supposedly making the product for a company which makes money by sending
products back and forth. This is the core domain of the application.

The basic idea is that a product P is moved from point A to point B, and in
this process, the company makes money.

The application will allow the company to make money by both being good at
organizing the workflow, and by making an existing workflow cheaper.

Let's say a product can be delivered to point C by taking the route A -> B ->
C, or the route A -> D -> C. The ERP must be capable of deciding which one is
better (in terms of money or time), and must manage the workflow it chooses.

So the whole point is supporting the movement of products around. Around what?
Around the world.

For this reason, let's first draw our first component: the World.

In a real project, I would continue by adding a Product component. I've chosen
not to yet, because this project is an educational one in nature, and I wanted
to get across new ideas about the architecture. If I had focused on the
products, I think there would be too much noise for the type of audience this
project is aimed at, a noise which would make the process of creating the
architecture and the architecture itself harder to understand.

We will introduce a Product component later, when the reader will feel at ease
with the architecture which, at that point, he will feel familiar with.

Instead of focusing on Products, we are going to focus on Users. This is,
incidentally, also the subject of the use cases we have drawn in the previous
commit. I think that any reader can relate to the concept of User.

So let's draw that component, the User.

Architecturally speaking, it's not that much of a difference between an User
and a Product. Instead of having Products moving around, we will have (for
now), users who live in the World and take different roles while interacting
with our system.

In the previous commit, we have concluded that there would be a standard way of
passing in data from the User to the system.

In terms of DDD (Domain-Driven Design), the data that gets into the system is
packed up as a Command. Since it looks like a good name, let's make a port of
the World component called Command Hub which will be used to receive and
process Commands from the outside.

Conceptually, the Command Hub will provide a Command Interface which any other
component can implement in order to send commands to the Hub, if it needs to.

We also want to make the components decoupled and thus reusable in different
types of applications, or to be able to combine them. This is achieved by
making an event-driven architecture.

For this reason, let's give the World component an Event Hub, which will
provide an Event interface.

But what will stich together these components?

This question is so pressing, because it's so central to our architecture, that
we will have to further investigate it.

1 个答案:

答案 0 :(得分：1)

这不是一个asnwer，只是一个不适合评论框的评论

（1）如果你想“教你的读者”你自己做不到的事情，那就是奇怪的做法。向您的读者展示适合您的方式。展示“你的火车运行”的方式，展示你在脑海中看到的心理图像，用你使用的任何可视化语言的纸/铅笔/照片

（2）您正在跳过uml-diagrams: UML 2.5 Behavior Diagrams没有用？即使uml-diagrams.org: UML Interaction Overview Diagrams无用吗？

（3）这个问题看起来过于宽泛（长篇）或许基于意见而且可能偏离主题更适合https://softwareengineering.stackexchange.com/help/on-topic

建议的建模工作流程

（4）

总结我的长篇评论，我没有看到你做过的任何错误。如果这是Test-driven Development和Domain-driven design如何为你工作的描述，你甚至下意识地使用它然后它就好了。 Being a good teach is not an easy task，祝你好运

相关问题
最新问题