I got two Activities called A("show login site") and B("show login site with error message"). And in the view from the software is A the generalised Activity from B.
Does UML allow a generalisation between them or should i ignore this?
Generalization relationships appear in class, component, and use case diagrams.
There is no "generalization" relationship between Actions or Activities in Activity Diagram.
Activity diagram are used to explore flow of business process or details of an algorithm generally.
So after your investigation you may wish to implement this in an object oriented way. In that case if you a decide to create hirearchy of Activities [ suppose A <|------ B (B inherits from A) ], then -if it helps you- you can show it on Class Diagram.
PS: A: show login site B: Show login site with error message MAY NOT truely show a generalization relationship in software perspective. (depends on your context).
Related
I am new to coding and I was wondering what is the logical way of representing the interconnections between classes of a system, more specifically the GUI class and the system's classes. Let's consider an online ordering system. In addition, let's consider that we need to make an order in this system. So I imagine that there is a GUI ( after logging in ) and there is a button for make order. So this means that the GUI class will be connected directly to the make order class ( if we assume that there is a class that is responsible for making orders )? Or there should be some intermediate class that should be connected to the GUI and controls the logic of the system ( if user choices make order then this control class deals with the make order class, if user choices to track order then this class deals with the track order class and so on )? I am looking for the most efficient way of writing code.
Edit: In many textbooks, they mention three types of classes that deal with this issue which are boundary class ( GUI), controller class and Logical class, but actually I don't know the exact meaning of the controller and the logical classes types.
MVC is one famous pattern used for this specific purpose. MVC stands for model view controller.
View = Classes responsible for the UI.
Model = This is the business domain where all complex business logic lives. OOP is heavily used here.
Controller = This connects the view with the model. Example - a click on the UI needs to be fulfilled by a model and the controller will connect the UI to that model.
Add REST to this mix which will help UI communicate with Model and the make the model agnostic to type of clients being Web, Mobile or even another server. Angular, React etc are heavily used for UI presentation.
You would needs a persistent layer to persist the state of the model and read it back. Example - A database which can save historical order and read them back. JPA and Hibernate are famous tools for this.
You don't need to deal this raw MVC, rather use one of many web frameworks which will take care of boiler plate code for you. Spring MVC is one such framework in Java world. There are equally famous frameworks for python, node, scala etc. This framework will have standard ways to do REST, Persistence, controller etc. So start from this.
I am trying to Create Class Diagram for my Web Application but i dont know how to Represent Database Connection and REST API in Class diagrams.
P.S. I am Creating Class Diagram by following model view controller pattern.
A class is a class
In your class diagrams, you model classes of your system. And all the classes look alike:
a database connection would be a class like another, that will keep some properties about the database context and offer methods for connecting to and disconnecting from a given database.
a REST API class would be a class (or a set of classes) like any other. If you're the API consumer you would certainly have no properties in these classes (because REST is stateless and properties create a state). You could for example have a method for every service you could invoke.
Conceptually speaking theses classes in your system are proxies for something which is out of your system, and which would invoke the APIs provided by the database and the webservice.
But perhaps you want to model something else ?
If your system offers an API, and you want to show how the API offered to the external world relates to your internal classes, you could be interested in using a composite structure diagram.
If you want to show the different components if your system, especially how these are wired together using an API, you could be interested in the component diagram.
If your question is not so much about the structure of the classes and the deeper internals of your system, but more about showing that some part are on remote servers or in containers, you could even think of deployment diagrams. But these are more about the concrete layout of the operating infrastructure, and to link it to the classes, you'd need the component diagrams first.
This is intended as a follow up question to RESTful API: Where should I code my workflow? A brief summary of the question (adapted to fit my question a bit better) would be something like this:
Each domain object contains business logic associated with the specific object in a certain bounded context (X). The REST API contains logic to transform the result of a query or command into data sent over the wire (JSON for example). When using HATEOAS and hypermedia we want to model relationships between resources using links. But in order to determine which links that should be returned by the REST API one often need to resort to business logic / rules. The question is, where do these "workflow rules" belong in a DDD application? Would they perhaps be in a different bounded context dealing only with the workflow rules (perhaps in a "partner"-like relationship with X) or would they belong in the X BC?
I'm not a DDD expert (only through 100 pages in Eric Evan's book) but I can tell you what happened in our case of a e-commerce catalog.
Initially we had such business flow in the same bounded context of the app based on data and the requesting user's roles/permissions we altered the state transitions (you said links, but this is really the heart of it, links are just one way to present state transitions) presented to the user. This worked ok, but it was a lot of repeated logic being executed. Then we added a search application that was a different bounded context as it presented the same data but in different collections/groupings and we didn't want to have them get out of sync.
We moved to a CQRS implementation, so a lot of our business logic is "pre-calculated" thus it's in something like a "partner context" as part of our projection from write model to read model. We don't store the links specifically, but instead flag allowed behaviours on the data. Both the catalog application and search application use this read model and it's behaviour flags to determine state transitions to present to the client.
Some stuff happens on the fly upon requesting of the resource, almost at the serialization step. We've targeted these to be moved to the pre-calculated as much as possible, but what we can't precalculate (only because of the scale) is stuff that is based specifically on the user. Like the recommended search which uses BI data within the search engine to return results. We could pre-calculate that for every single user, but the numbers are too huge for our systems right now. So we send the main apps calculated resource (from the main context) and pass it through yet another partner context to further refine things.
another use case is some links are only presented to authenticated user, and thus are hidden from anonymous users. We do this in the main apps context but it's starting to be a bit of a hindrance because their presence indicates what the user behind the request can do in other apps (like change password), and our context isn't really the authority of what the user can do in some other app. It would be nicer to hand the resource off to their context and have them process it before we return it to the user. One simple solution we used for this was instead of deep linking to functions within the external context, we link to a root resource of that context and allow it present state transitions. It means there's 2 requests, but it cleans up the locations/authorities of the logic.
The workflow is actually composed of domain knowledge and hateoas infrastructure.
If the application is not designed with hypermedia, you may not even need the hateoas part. But the domain knowledge still exists, they just live in the end users' minds. You need domain knowledge to validate the user's command just in case they forget it.
So for hateoas, I split workflow implementation into two parts: Domain models and hateoas infrastructure.
The domain models tell the domain knowledge.
The hateoas infrastructure, on the other side, is hateoas specific, put them out of the domain.
Here is a java example, using springframework-hateoas. I put the workflow in the procedure of mapping domain models to resources.
#Component
public class OrderResourceAssembler extends ResourceAssemblerSupport<Order, OrderResource> {
#Override
public OrderResource toResource(Order model) {
OrderResource resource = mapToResource(model);
resource.add(orderResourceHref(model).withSelfRel());//add self link
if (model.isAvailableToCancel()) { //let the model tell
//add cancel link
resource.add(orderResourceHref(model).withRel("cancel"));
}
if (model.isAvailableToPay()) { //let the model tell
//add payment link
resource.add(new Link("http://www.restfriedchicken.com/online-txn/" + model.getTrackingId(), "payment"));
}
//etc
return resource;
}
// omitted codes
}
If the model cannot tell on its own, you may introduce specification object to do the job.
Wherever the resource resides is the same place that needs to marshal the access to it.
Say you've got a larger system with three bounded contexts: employee management, customer intake, and service provisioning.
GET an employee's information from employee management? Deciding whether to show the link that can be used to POST or DELETE a role is for employee management to decide.
GET a freshly submitted service contract from customer intake? Deciding whether to show the link that can be used to PUT up a revision or POST follow up details is for customer intake to decide. Sure, employee management presides over the handing out of the roles necessary to work with new service contracts, but customer intake is responsible for knowing which claims and other conditions are required, and will ultimately ensure that everything checks out.
Likewise, GET a physical installation's software profile from service provisioning? Service provisioning is going to need to make sure that everything is in order with other services/contexts (customer's account paid up, current user in the network services role, device not locked out for maintenance) before it gives out the link where you can PUT the new quality of service specs.
These kind of 'workflow' decisions are integral to each context -- they should not be split out elsewhere.
I'm about to develop this small website, its basically a simple web app to store informations about patients for a doctor.
The company i have got the assignment from demands an introducton with a class diagram, honstly, i have done this already but only for standalone apps, i'm very new in designing class diagrams for websites.
What i'm using is the Ivar Jacobson's iterative metho with usecases, where a usecase includes:
Actors, scenario (representing user-system interactions when all goes fine), and worse case scenatio (solutions when something goes wrong).
By applying this i came to a good conclusion, a well prepared class diagram.
My problem is that i'm doubting whether or not i should include jsp views and servlets(in my case action beans since i use Stripes) in the diagram, i mean, the bridge between the business-classes and the user are the jsp-views and the provided info are going to be processed by the servlets (or action beans), would you include them in the class diagram?
For a small project tis might be not that relevant but what if you have a project with 30 views and 20 servlets, the diagram would become messy and huge.
Do you have some tips about it?
Thank you
If the only reason you need the class diagram is to satisfy the client, best find out what they're looking for first.
If however they're not specific (and ignoring the cynical options) I'd suggest the following:
Create a "Domain Model" diagram. i.e. capture the concepts in the domain and their inter-relationships. So Doctor, Patients and associated stuff.
Don't create a "design" class diagram - i.e. no jsps, servlets, etc. If necessary create a simple architecture picture instead showing how the application is layered.
Rationale: a domain model is good for checking scope and verifying domain rules (relationships). A "design" class diagram only obfuscates that. A proliferation of jsps, controllers, etc. hides the underlying architecture pattern while distracting from the useful stuff in the domain model.
hth.
I have read a lot of gwt-mvp questions that are asked here, but since i'm totally new to this design pattern I would like to ask some questions:
[1] The Activity-Place pattern is a different pattern than mvp?
[2] In the MVP pattern presenters contain the logic. Now the logic of the widgets/controls is defined in the Activities?
[3] The CustomPlace classes are fixed (as the Eclipse plugin constructs them) or can i put data/methods and what kind?
[4] What is the use of the Presenter interface inside a CustomView? What data/methods would make sense to add into it?
[5] I want to build an application that will use many data structures that will be saved into a database. I have read some other posts here and I will make the Model part of MVP live inside each Activity. So i think to create each time the data structures of each activity at start and load its values (if necessary from db) and will update the database after the user goes to another view. What do you think about this approach?
Let's start by debunking one myth: Activities/Places have nothing to do with MVP. Places is about navigation, Activities are about "componentizing" the UI wrt Places. On the other hand, MVP is a design pattern, it's about how to organize your code.
Many people are using their activities as their MVP-presenters, but it's not enforced. The GWT team is trying a new approach where the activity is distinct from the presenter (work underway in the mobilewebapp sample if you want to follow what's going on there). You could also have your activity being your view and making use of an "internal" presenter (similar to how Cell widgets work)
A Place is more or less a URL. You can put whatever you want in it. I'd suggest making places immutable though: build a Place, goTo it, make use of its properties to build your UI.
That's about MVP then. This is only needed to decouple your view and presenter, mostly to make mocking in unit tests easier (this is particularly of the view interface though, not much for the presenter one, unless writing a test harness for you views). In some cases, you might also want to use the same view with distinct presenters; they'll all implement the same interface so the view can talk back to them.
How about the closing of the window/tab? I'd rather use a periodic auto-save, or an explicit save button; and implement mayStop so it prompts the user when there are unsaved changes (similar to how most desktop office apps work —e.g. MS Word or LibreOffice—, and GMail if you try to navigate away before your mail draft is auto-saved)
The Activity-Place is an implementation of the pattern. Google introduced gwt-mvp pattern at Google IO, but only provided it's implementation as part of GWT about a year later.
Yes Activities contain business logic. No, widgets/controls usually do not contain any logic, they just fire events based on user action. The logic that acts upon those events is written by user and resides elsewhere.
I don't use Eclipse, so wouldn't know about Places generated by it. Normally custom Places can contain custom fields and methods. For example they can contain custom place token arguments, i.e. if place token is "#place:id1", than your custom Place could contain field holding this argument.
When View needs to call/access Activity, it does so via Presenter, which Activity implements. For example when user enters all data in a for and presses submit, then you could have a method in Presenter named submit(formData).
Preparing/loading data in activity.start(..) is a normal way of doing things. If particular activity is used a lot, then you might consider caching the data if appropriate.