I'm trying to develop a web-app and some desktop apps, all of these apps communicates via database or socket tcp. These desktop apps are running in background so, there is no use cases and the web-app is only used by remote users.
And, these desktop apps communicates with the web-app via the DB and vis versa.
Which UML diagrams may help me to conceptualize the work of the desktop apps, please?
I've tried to conceptualize this thing using the deploiement diagram, but, I think that it's unsufficient to explain the whole work in a report. Isn't it ?
Thanks a lot!
If you read up on the theory of use case diagrams and actors, you will see that an actor (something that interacts with a use case) can be a person or another system.
In this case, since your app is running in the background, is must be triggered by something: by a person or by a job scheduler (=a system). That means that the triggering is done by an actor, since an actor can be a person or another software system.
So that means you have a use-case (your app) and an actor (scheduler or person). In that way your background app can be described as a use case in a use-case diagram, together with the rest of your system.
As Rolf Schorpion told, you can still use use case diagrams with systemic actors. Just make sure that actor is something external to the system (or part of the system). A typical actor can be Timer (if it is time-controlled).
Besides there is a plenty of UML-diagrams you can use. From the short desctiption you posted, I'd recommend the following set of diagrams (at least these are the diagrams I'd asked you to prepare in order to better understand the system you briefly described):
Mandatory:
Component diagram - showing structural organization of your system and their dependencies (desktop app, WEB app, DB are components)
Deployment diagram - showing the network organization, servers and how the previously defined components are actually deployed on server nodes
Sequence diagram(s) - showing the important communication scenarios between the components. You mentiones TCP, so this can be further refined and displayed using one or more sequence diagrams. It there is a standard communication pattern, a single sequence can be enough. Otherwise, several sequences can be used to cover all significant communucation scenaria
Optional:
Class diagrams - to specify internal components structure - design (blue print of the source code). I recommend this one only if there is a complex design in each compoennt, worth this effort. If not, it could be costly to keep the model in sync with the actual code.
State disgrams - if a class of componen show a behavior that could be modelled as a set of discrete states (e.g. ON, OFF, IN REPAIR, OUT OF ORDER), this diagram is very powerfull and highly recommendedn
Activity diagram - if you have some interesting non-trivial algorithms or simply want to show an overall system logic in terms of sequenced tasks, use activita diagrams.
These are the most common UML diagrams. Besides you have a couple of them more that couls be used in some special conditions (timing for example), but I'm sure you can model almost everything using only these. Use case is far from the first choice for UML modelling.
If you have some further questions or doubts, just ask.
Related
What type of UML diagram should I use to model the parts of a web app?
For instance, lets say my parts are as followed:
Server
Database
Web App
Multiple APIs
The web app interacts with all the other parts in some way. From my research, the best options seem to be either component, deployment, or sequence.
Here's a general idea that I'm going for with my diagram, but I do not know which UML diagram this would best be represented in.
If you know the diagram I should use, I would like to know how each part is represented in the diagram. For example, in a deployment diagram, I know that a server/database would be nodes. And, APIs would possible be artifacts?
For designing a web app (or any other type of software application), following a best practice Model-View-Controller (MVC) codebase architecture, you first need to make an information design model, typically in the form of a UML class diagram, defining the model classes, or the "model", of your app. The "view" (or user interface) of your app is based on the model.
Your diagram attempts to model the deployment architecture of your app. But this question comes after choosing a codebase architecture and an information architecture.
You can find more explanations about the architecting process, and the code of several example web apps, in my book Web Applications with JavaScript or Java, which is also available as an open access online book.
This depends a lot on what you're wanting to model and communicate. All of the diagram types you mention would be useful ways to describe a web app. Each focuses on a different aspect of the web app -- component models are about software component structure (database, web app, apis), deployment models show how instances of these components are deployed into deployment nodes (servers, devices etc). Like Thomas says, this is a very broad question -- in essence you are asking how should you describe your web app's solution architecture which is not a trivial exercise. Is there something more specific I can help with -- can you narrow down what it is you want to show about your app?
Your start with the component diagrams is fine. Generally your question is too broad to be answered here, but a few bread crumbs anyway:
In a next step you can describe the single components which are hosted inside the single nodes. You can make the nodes navigable (means you have a composite diagram showing their guts) so you can place component instances showing their interfaces. The latter can be shown with either lollipops or as stereotyped classes which the single components implement. Following that you can break down components in a similar fashion showing how the components are implemented with various classes and how these realize the single interfaces. It's possible to show the interfaces outside the components and <<delegate>> them inside the specific classes.
The story goes on, but it's too big to be told here.
I've been reading about DDD and bounded contexts and I think I'm getting the idea wrong. At first, I liked the idea of subdomains and bounded contexts, I understood it like that: there's a software to be developed, but attacking all at once is too much, so we break it into logical pieces and develop each at once. Another problem we solve is ambiguities on the ubiquitous language.
This led me to think about bounded contexts as basically just folders where I group and bound code related to some specific piece of the application. This code I believed to be made up from things like
The domain model of that bounded context, including abstractions for repositories and services
Infrastructure layer for that bounded context, implementations of repositories and so on
Of course, being the domain model and infrastructure properly separeted within the bounded context.
Reading further, it seems, however, that each bounded context is an entire application on it's own right. It seems, sometimes, that each bounded context has it's own application layer, for instance.
This made me confused, because sometimes I don't want to end up developing tons of applications, I just one to develop one. The bounded context division of the application was supposed to build one app, not many apps to be integrated.
I've seem this question where #MikeSW says both approaches presented by the OP are valid. What I'm asking is about a third structure:
<bc 1>
|_ domain
|_ infrastructure
<bc 2>
|_ domain
|_ infrastructure
|_ application
|_ presentation
At least for all the applications I've seem this makes much more sense. I want one app, not several apps with several presentations, but I still want to be able to break the domain and benefit of things like "bounding the ubiquitous language".
So, is a bounded context a full aplication? Or can a bounded context be used like I understood and felt more useful? There are any problems with my approach?
The domain layer is usually the most complex part of your program, and can also change often due to business requirements and refactoring. So you generally don't want to expose it directly to your presentation layer or other bounded contexts. If you feel that you can expose it, it might be the case that your application logic or use case methods are mixed into your domain layer, or that your program is not large or complex enough to require multiple BC's to begin with. Otherwise, I would go with including the application layer in each BC to protect the domain model's integrity and expose only the commands that need to be called from a use case perspective.
I want one app, not several apps with several presentations, but I
still want to be able to break the domain and benefit of things like
"bounding the ubiquitous language".
You can have a thin application layer for each bounded context, and still have a single presentation layer. This is sometimes called a "composite UI", which should be considered a separate BC in itself. If you need to handle common logic such as authentication, create another application service or facade in the composite UI and have it handle the authentication before in turn calling the application service of an outside BC.
I think most of the examples you see in books and on the web are over-simplified in that they have 1 BC per physical running application (and perform some kind of network communication between them), whereas in the real world you might have a complex application that you need to split into separate logical units, but not run them as separate processes unless the need arrives.
At the end of the day the answer is both. The important thing to take away from bounded context is not how you structure your app, but that you have different spaces where you model specific behavior relating to some context. How you define the boundaries between these contexts is dependent on the problem you need to solve.
There is nothing wrong using namespaces(folders) to define bounded contexts. Like you said most of the time you are simply writing one application. You can also define your bounded context by having separate projects for each context. In this case your presentation layer will reference the project it needs.
There are many right ways to code DDD. You should ask yourself "Am I following the core principle by doing it this way"
The bounded context describes a subset of the complete solution and everything within that context serves that context. So, imo, each context has it's own domain so it could be a separate application or just a subsystem of the same project. The point of the "context" is that the ubiquitous language applies directly TO that context. For example, a User in the Account context might mean something completely different than a User in the Sales context. Each "User" will have different capabilities and follow different rules in each context. Each context needs to be isolated from any other context and are not allowed to share references (unless it's via a 'Shared' context); any communication should be mediated through a service that sits on top of that context. A context doesn't even have to follow DDD to be "DDD compliant" since each context can follow it's own approach (e.g. domain driven, data driven, etc.). Contexts are simply silos that outline a logical section of the business.
Whatever you need to do to prevent direct references across contexts is fine whether that means different namespaces, different assemblies within a solution, or different projects altogether.
The bounded context is the scope on which the code operates. It relies on a domain model, that can be supported by a ORM (or not). It implements different kinds of services (domain services and application services) but its aim is to expose only domain services to its environment. DDD is a service oriented architecture, meant to work as offline as possible and in a loose-coupled way. You may decide to consume your services in different ways. The solution implements different kinds of components, different kinds of layers, different kinds of projects. I believe the most critical attention must concern the model, that should not be distributed across components. Solution design and domain model are orthogonal purposes.
I currently work on a rather large system that consists of a WinForms app that uses WCF services and a database at the bottom. If you think about a use case or a requirement, what a developer needs is a quick overview of the implementation of that particular use case (or requirement). A person who knows the systems could very quickly verbally explain that these two views (or subviews) are used in the UI, they are data-bound to this controller, which uses this WCF service to get this DTO. The service uses this business class, which uses this data adapter, and the data is in these tables in the database.
I think in most cases it would be possible to convey all this information in a single diagram. However, it would be a kind of a hybrid between component and activity diagrams as it shows both workflow and the components that are involved. UML obviously doesn't have such a diagram, but I was wondering if anyone has done anything on these lines and what tools you have used.
I dont think activity diagram is appropriate here. Activity diagrams, as far as i believe are intended for somebody to understand how the module/system works without getting into the technical part. But then if you can express all that what you said in an activity digram and if your team and your audience are able to decipher things, then sure. Getting back to your scenario, i have done this before and a UML sequence diagram has helped me here. A sequence diagram depicts sequential object interactions. You might wanna check it out
I'm developing a 3 tier based system , the user passes data to the server which performs server side processing and queries a database etc the usual stuff. I'm wonder should I include the database in the diagram as an actor ?. I have already included the server as well as the end user
Thanks.
If you're developing the full system then no, don't include the DB as an Actor. I wouldn't recommend showing the Server either.
The purpose of a UCD is to show the system context in terms of the features (Use Cases) it supports and for whom those features are provided (Actors). UCDs deliberately don't show internal structure - so you focus on the Users and their Needs without getting sidetracked by implementation concerns.
Since the Server and DB are part of your system they're "design detail" for how you realise the Use Cases. Therefore the don't sit outside your system, therefore they're not Actors. The only time I'd recommend putting other systems on a UCD is when (a) they're external to the system you're building and (b) provide or receive some value to/from it.
UML provides other diagrams for showing the internal components of the system:
Deployment diagrams show physical hardware and allocation of software components to them
Component Diagrams allow you to show the logical structure of the application
Sequence Diagrams or Activity Diagrams allow you to show how a Use Case is realised in terms of its logical components
(Note I'm not suggesting you use all those, just what's useful).
hth.
i think the web servers and the database should labeled as the system, users or external third parties could be actors!
I have to develop an integration concept to integrate my software as a subsystem into an enterprise information system which communicates with other information systems in other institutions.
I want to show a diagram which explains how the several subsystems are connected and which data is communicated between the subsystems. My problem is that I'm not sure if there is in the UML language a diagram-type that supports modeling of complete information systems.
I thought about the deployment diagram, but I am not sure if it is the right. I don't want to start an then recognize that it is the wrong way.
Is there any advice which diagram should be used, or if there is an alternative modeling language for complex information systems?
A component diagram is what you want - see chapter 25 of "The Unified Modeling Language User Guide".
I want to show a diagram which explains how the several subsystems work together and which data is communicated between the subsystems.
I'd probably start with a conceptual sequence diagram.
So, for example, you could have your lifelines represent the various components that you're integrating with, and your interactions could be any of the messages that need to transfer to and from those components.