I know that Component Diagram represents the architecture of some information system or the overall system, so it's necessary to mention the components that represent external databases used by the system.
My question is:
What if the application uses an internal database that lays on the same computer where the application is. Should it be represented as a separate component or a component with the system name is enough with its interfaces?
It depends what do you want to show on the diagram.
If you're focusing on detailed application architecture you still might want to show database as a separate component (since that's what it is in reality).
If your goal is to show application decomposition you can probably completely omit the database in the diagram. That's valid especially if your queries are embedded into the application layer other than database itself. If you have a dedicated database code (do database offers some sort of API to the component) you'd usually always represent that as a separate component.
The actual location of a component is irrelevant on a component diagram. It's natural that some components share the same execution environment.
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'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.
I have a number of XPAges design elements that I use in many different databases. If I read the wiki correctly the single store is an all or nothing situation.
So I want to create unique design in a database but use the set of reusable XPages element from a single store location. the wiki says:
Apart from the "dummy or blank XPage with the same name of the default XPage" in each instance application, does it matter if an 'instance' contains XPage design elements?
No. If SCXD is set on an application all XPages design elements are ignored on the database and the application uses the design elements on the SCXD database.
If this is the case then I have to create databases where probably 75% of the code is reusable but I would have to repeat it (and maintain it) in dozens of separate databases. pity!
XPages and related elements (Custom Controls, SSJS Libraries, Java Code) can be inherited from a specific template like other design elements. So, I would setup a database called, perhaps, "Core Components" (.ntf or .nsf) with a template name of "CoreComponents". Then on the individual elements in the target DB you would set inheritance to be specifically from the "CoreComponents" template. Then the elements that are unique to each database do not inherit from any template. You can then use File-Application-Refresh design to update the elements with specific inheritance and the one which are unique in that database will not get overwritten.
You do need to do a clean build after the refresh, so I recommend that you keep the Core Components database locally or on a different server than the others so that the daily design task will not update them resulting in corrupted xsp elements.
IBM's preferred model for reusing XPage artifacts across multiple applications is to create OSGi plugins that leverage the XPages Extensibility API.
NotesIn9 episode 64 demonstrates how to make an existing Custom Control design element a library component, which can then be used in any app that has the library available, instead of having to copy the design element to each app separately. Any subsequent changes to that component are then applied immediately to any apps that use it when a new version of the library is deployed.
If you truly have "dozens" of apps that all share certain features, but the entire design should not be identical across all of them, then the OSGi model is definitely the way to go.
But why not flip the entire model on its head? Traditionally, we've always put the code and the data in the same place (e.g. same NSF) because it was a pain to access -- and, especially, visually represent -- data in one NSF via code in another NSF. That's not true anymore. Why have dozens of apps just because the data lives in dozens of places? Any data source in XPages can be told where the data lives... you can link a central user interface to any number of "remote" data stores (either different NSFs on the same server, or even databases on other servers).
Red Pill, for instance, takes this to its logical extreme: they deploy one NSF, which acts as a portal to all your data, no matter where that data lives. The ACLs of the various NSFs (and Readers fields) still ensure that users don't pry into data they haven't been granted access to, and they have complex analytics algorithms for determining which data the users will actually care about. But if you have 500 NSFs in the domain, you're not maintaining 500 different code templates... it's literally just 1; but that one user interface is how users find, and interact with, all their data.
You certainly don't have to take this premise to that extreme, but perhaps you could identify, say, 5 apps where the UI and / or business logic is similar (or even identical), but the data just lives in multiple places. Create one central app for interacting with all of that data. Create a "homepage" that gives users a way to select which "app" they're trying to access (or, if they should only have access to one to begin with, compute which one that is), and then once they navigate in to the specific "app", just bind the data sources to the relevant NSF instead of assuming each view or document lives in the same NSF that the code does.
It's still a good idea to be aware of the Extensibility API, not only for the sake of code reusability, but also to understand just how much of the behavior of the platform truly is within our control now -- provided, of course, that we're willing to occasionally write some custom Java code. But if you shift away from the one-to-one mapping between code and data that we've habitually maintained in Domino for so long, I can practically guarantee that you'll prefer this approach... both for the ease of implementation and maintenance, and for the comparative simplicity it offers to end users.
You can combine the template technique and the all-code-in-one-database approach:
Divide the application design into two parts: a data part and a code part.
The data part contains all Notes views. If it's an classic Notes application it would contain also all design elements for Notes client like Forms, Subforms, Frames and so on.
The code part contains all XPages, Custom Controls, CSS, client/server JavaScript libraries, Themes, images, jars and so on.
Put your 75% common code into masterData.ntf and masterCode.ntf.
The application code databases appCodeX.ntf inherit all design elements of masterCode.ntf and contain the additional application specific design elements.
The code from all application templates gets united in allCode.ntf. It inherits all from masterCode.ntf and inherits the additional pieces of code from application templates.
Based on that you create an allCode.nsf.
On the data side you use the classic template way.
From here you have to possibilities:
You use Single Copy XPage Design - connect every appData database with allCode.nsf
You connect your XPages in allCode.nsf with appData databases
I prefer the latter. You can define in allCode.nsf where all the application data databases are located, e.g. in property documents.
With the approach showed in picture you're still able to separate application easily e.g. in case you want to sell them. You have already a separate template for every single application.
I'm a beginner in DDD and am facing a little problem with architecture.
Our system must be able to export business data in various formats (Excel, Word, PDF and other more exotic formats).
In your opinion, which layer must be responsible for the overall process of retrieving source data, exporting them in the target format and preparing the final result to the user ? I'm confusing between domain and application responsibilities.
And regarding the export subsystem, should implementations and their common interface contract belong to the infrastructure layer ?
Neither Application nor Domain layer or any other 'layer'. DDD is not a layered architecture. Search for onion architecture or ports and adapters pattern for mor on this subject.
Now to the core of your problem. The issue you are facing is a separate bounded context and should go to a separate component of your system. Lets call it Reporting. And as it's just a presentation problem, no domain logic - DDD is not suitable for it. Just make some SQL views, read them using NHibernate, LINQ2SQL, EF or even plain DataReaders and build your Word/whatever documents using a Builder pattern. No Aggregates, Repositories, Services or any other DDD building blocks.
You may want to go a bit further and make all data presentation in your application to be handled by a separate component. Thats CQRS.
I usually take the simple approach where possible.
The domain code implements the language of your domain - The nouns, verbs etc.
Application code creates poetry using this language.
So in your example the construction of the output is an application concern, while the construction of the bits that the application will talk about (since you don't mention it) would the the domain concern.
e.g. if the report consists of sales data, that things like dates, bills, orders etc. would be abstractly constructed in the domain, while the application would concerned with producing documents using these.
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!