When it comes to systems integration, how do you model integration requirements? Do you use UML or BPMN or some other techniques?
What limitiations you see in existing approaches and what would be an ideal modeling approach to system integration requirements in your opinion?
This question is really broad and could be refined (e.g. what level of system?) if you desire a better answer. The approaches below have worked in my experience and were adopted broadly within a company. This may not work for your organization, but our is very application/data integration oriented and these methods help us track integration at high/flow/data entity levels. The key to success is not the ideal model, but a practical one with good training and examples/cheat sheets.
One UML model view that seems to work will for system integration at the component/interface level is a component diagram with components and then interface realizations and interface usages drawn out.
Also using the concept of information flow either UML or just lines with a definition. Then just pick your level of abstraction. Example: PeopleSoft --- (Person Details via File) -----> Active Directory --- (Groups via LDAP) ----> Training Tool.
BPMN is for business process really and though I really think it is great this is not where it should be used.
OMG has tried to answer to your question with the requirement diagram integrated in the sysml modeling langage. SysML tools providers try to solve your problem. For instance check out rational rhapsody solution.
Related
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.
We're starting a web application using DDD and CQRS (using the ncqrs framework) and before we get started writing our own infrastructure class library, i wanted to see if any are already available.
I'd think at least some basic interfaces and common implementations for writing to the file system, sending emails, etc could be used in any project.
Those types of services are sufficiently context dependent to be unyielding to common frameworks above the facilities provided by the .NET Framework. There may frameworks centered around specific tasks, such as emailing, however you're better of selecting a solution that fits the requirements, instead of the converse. Instead, consider reviewing some sample DDD projects as listed here.
I agree with what eulerfx stated earlier. I'd add that if you depend upon a framework for using DDD and CQRS, then you risk depending on the framework and not truly understanding what is happening. As a result, you may miss what DDD (and CQRS) is providing to you.
I will state that I started off learning about CQRS by using a framework (NCQRS in fact), but my DDD knowledge was based on Evans' book and I didn't look for a framework for modeling my domain. As each domain is unique to the problem, I think it's hard to truly have a framework that "helps" you implement DDD.
In retrospect, I wish I had not gone with NCQRS right from the start as I missed or passed over some of the subtleties of the CQRS pattern.
There are probably some DDD frameworks out there, but I'd recommend forgoing them and build your own. You'll thank yourself later.
Hope this helps. Good luck!
You can try my library CoreDdd, documentation here, blog posts about it here. It contains support for DDD (entities, aggregate roots) and CQRS (commands, queries). No support for writing file system or sending emails, use standard .net for this.
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 am working on a Social networking site. I have to create High level design document. In this document there is one section "Application Architecture diagram". I haven't worked on architecture diagram. I know what will be the architecture of our application as it is explained by my Senior. but I don't understand the concept of "Application Architecture diagram".
What should be included in this diagram? Where to place which components? Can anybody help me to understand how to create application architecture diagram
according the application you developed, specify the technology you will use for developments with your project functional flow. They will be represented as diagrammatically. It will contain (i) Functional Flow, (ii) Process Flow, (iii) Unit test cases. Otherwise ask your senior regarding this.
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.