I have Googled this but couldn't find a good answer. I understand that they are closed related. If someone has a definite answer on what the difference is I would be very grateful. Thank you.
System image is the authoritative combination of all available information. The system image is the collective, sum total of all information about a product such as manual, internet forums, physical appearance including signifiers and affordances. There is only one system image. A conceptual model on the other hand is the understanding about a product that is formed by the user. Every user has their own conceptual model which may or may not be accurate, and it may change with every interaction with the system image- that is a conceptual model may change, as one's understanding may change. Everyone's conceptual models are different, but every person has only one conceptual model of a product.
Related
I'm currently reverse engineering a ticketing system (a ticket booth system with human operator), in order to create a technical manual.
What I want to do was a flowdown from all the functionalities modeled as a workflow from the user PoV using a UML activity diagram. The objetive in this is to first lay the workflow of the user, to than specify all the interfaces/communications with databases and central systems and all the classes as class diagrams, regarding the functionalities displayed on the activity diagram.
The problem is that the system has so many options, like buy ticket, recover ticket, client info, shift managemen... the first problem i got is when i got to the main screen activity there are so many branches that i dont know if i could use a Decision point on the activity diagram.
Anyone can shed some knowledge here? Thanks to all. Cheers.
Even the system is already there the approach for building the model should be pretty much the same as if you were doing the analysis from the start. The main difference is you refer to how the system is actually used, however it's also a good occasion to discover the pain points in the current system.
Your use cases, scenarios etc will be based on what the system currently does.
Don't try documenting a complex system with just one diagram or even one type of a diagram. This approach will most likely fail. In a best case scenario you'll end up with something but it'll be difficult to impossible to read and comprehend.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In Eric Evans book on domain driven design it is written:
Domain modeling is not a matter of making as “realistic” a model as
possible. Even in a domain of tangible real-world things, our model is
an artificial creation. Nor is it just the construction of a software
mechanism that gives the necessary results.
Now I have two questions:
Should a model be designed
somehow that it could evolve to a more
realistic shape whenever NEEDED
without touching the core model in previous iteration?
If the answer to the previous question is positive, where can I learn how to create realistic core models?
Again if the answer to the question one is possible, would a day come that our model reflects any problem in the world?
Domain Model should not reflect real world.
It should only show one point of view depending on the context.
Let's say we got a glass.
One may think, well it's a glass and we can fill it with water. It is used to drink.
Other may think, well it's a product and we can sell it.
Another one may say, glass an inventory item. I don't care how does it looks like, but how many glasses I got here.
Depending on the context, we model glass differently. Still it is the same glass, but means something else.
All information related to the subject you can find on Udi Dahan's blog.
And more in the subject of modeling reallity, can be found here Don’t try to model the real world, it doesn’t exist.
Should a model be designed somehow that it could evolve to a more realistic shape whenever NEEDED without touching the core model in
previous iteration?
No, a model should reflect the particular problem under consideration. If the underlying problem changes, the model should reflect it. Let's say your modeling a hotel reservation system, a warehouse system, or a store point-of-sale system, your model should be a representation of the current concepts in those domains and the interaction between them. Models are not versioned over time.
2 and 3
No.
In a problem domain, there are obvious things and hidden things.
If you just model the obvious, apparent notions (whether real world objects or intangible concepts), creating a class for each one, you will have a realistic model but it will miss the point. It won't be a deep, insightful domain model.
To go beyond mere realism, you should sit with a domain expert and try to discover the hidden things in the problem space that will be helpful to the solution space - your application.
For instance, talking to a railway traffic expert, you might uncover heuristics or properties in the way train departures and arrivals are orchestrated that even the expert didn't realize or put a name on before. Naming these things will allow you to reason about them and ultimately act on them in your application. Or, you might have an elephant in the room - a big, widely used historical concept - and decide to reject it from your ubiquitous language because it doesn't describe a subpart of the problem accurately enough.
Realistic here is meant as opposed to refined, rationalized, not to totally made-up.
Somewhere far, far away in a domain galaxy there is mention of
'Measurement values' and 'Places'
Each 'Measurement value' comes from/belongs to a specific 'Place'
Each 'Measurement value' is registered on a given date & time and of a given, specific type (eg. waterflow, wind, etc)
Each 'Place' has a name and a collection of 'Measurement Values' that gets registered
Given my current model where 'Places' are the aggregate root that holds 'Measurement values' I have a dilemma:
Users wishes to view one type of measurement values at a time and there are quite a lot of measurement values.
To load all measurement values when only some of them are needed seems unneccessary..
Eg. Im stuck on how to organize/model the need "Show me waterflows (measurement values) in River X (Place) between time A and B"
Is it allowed to instantiate River X aggregate root only partially loaded with the type of measurement values concerned in a given use case?
Are there other ways of modelling measurement values and their origin?
Please let med know your thoughts...
I think that your aggregate is consistent as it is. Your dilemma as nothing to do with domain model but rather than with a presentation model.
I will consider the possibility to deserialize each measurement in a NoSQL instance, in this way your presenteation layer could filter and make any query without affecting the consistency of domain layer.
Correct me if I'm wrong but it sounds very much like the data model and storage are impacting the design of your system? If this is so it may be the cause of your dilemma. A key part of the benefit modeling using aggregates is it is free of dependencies. Dependencies such as databases and data models. There is no direct 'view' of an aggregate, so it's not shaped by the view. This makes aggregates much easier to design. They are much more focused on solving the problem. And are therefore great candidates for doing complex stuff.
If it turns out you don't need aggregates to model your domain. You can then just focus on an efficient storage and retrieval mechanism.
In other words...
Don't tie yourself up in knots doing DDD if you don't need to.
If it helps I created an infographic on common DDD mistakes. You may find it helpful. You can find it here.
By the way, I think DDD is a great way to go, but only if your domain warrants it. Appologies if I have misunderstood you.
I fail to see the real problem. You said that each Measurement is tied to a specific Place, then you don't have to load all Measurements.
Using correct data layer configuration, you can load the required Measurement by selecting/loading/instantiating only it's parent (Place).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am working on an open-source project which shows how to develop software iteratively using test-driven development and some ideas from domain-driven design. I know what I would do, however my formal skills (especially regarding UML) are a little bit rusty.
Below I am going to post my first steps with the diagrams and the explanations I would give to my readers.
I have the following questions:
The last step ends with the question But what will stich together these components?. How to show the reader the way in UML terms, while not skipping anything in the train of thought? What I plan to do is to let each component provide an Environment class. For the purpose of testing, a TestingEnvironment will gather all those environments and inject the right callbacks into the World. But which types of UML diagrams to use for showing my train of thought, and in which order? My problem is, somehow, that I know what I want to do, but I can't rationalize it to myself why I want to do it that way - I guess it has gotten a part of me to the point I don't make such decisions consciously any more.
What mistakes have I done so far, how to fix them, and most importantly: WHY?
Step 1
(0001_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.
Step 2
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.
This is not an asnwer, just a comment that would not fit into the comment box
(1) if you want to "teach your readers" something you can't do yourself, it is strange approach. Show your readers the way which works for you. Show the way "your train of thoughs runs", show the the mental images you saw in your mind, paper/pencil/photo in whatever visualization language you use
(2) you're skipping the uml-diagrams: UML 2.5 Behavior Diagrams as not useful? Even the uml-diagrams.org: UML Interaction Overview Diagrams not useful?
(3) this question looks like too broad(long) perhaps opinion-based and perhaps off-topic much more suitable for https://softwareengineering.stackexchange.com/help/on-topic
(4) for the recommended modeling workflow look at
(4.1) Cangnus's sequence diagramming comment in Stack Overflow: sequence diagram for books exchange
(4.2) BobRodes's use case scenario comment in Stack Overflow: Formal language for UML sequence diagrams
(4.3) Scott W. Ambler's Agile Modeling: Where Do I Start? for what when how and why Agile Modeling Best Practices
to name just a few
In conclusion of this my long comment, I don't see any mistakes you did. If this is description of how Test-driven Development and Domain-driven design works for you so well that you even use it subconsciously then it is just fine and ok. Being a good teach is not an easy task, good luck
Just wondering if anyone can give me feedback on my class diagram. I want to make sure it's correct and also any changes that are needed to it.
Thanks
Image link: http://i.stack.imgur.com/k4RA2.jpg
Difficult to provide a definitive answer without knowing the specific rules & requirements of your domain. However: assuming there's nothing unusual, some observations:
Can there be multiple performances of the same show? e.g. "Glee" being performed on Fri, Sat & Sun eve. If so you may want to separate out 'Performance' from 'Show'. (Each Show is performed many times, a Performance performs exactly one Show). Bookings are typically for a specific Performance, not the Show.
How do you know which seats are in which venues? More specifically, which seats in which venues are booked for which performances, and which seats remain free? Suspect you're missing one or more relationships among Seat, Venue and Show (Performance).
How do you know which Seat, Venue and Performance each Ticket applies to? (Generally speaking, a Ticket will have all of those printed on it).
Is it really OK to make a single Payment for many Bookings? (It might be, just checking).
More generally I'd recommend naming the association ends - preferably with verb phrases, not role names. It really helps readers understand the relationships - as well as helping you (the modeller) ensure you understand the domain.
hth.