I am writing up a design for a project I am about to embark on and I am wondering how I should be representing the view (the jsp files) in the UML class diagrams I have created. Since jsp files aren't classes do they fit in here? I'd think not since this is a class diagram but I'm not sure how else I should be representing these, any ideas?
Asked
Active
Viewed 3,604 times
3
-
When running the webapp, all JSP pages will end being compiled as an `HttpServlet` subclass. – SJuan76 Jan 01 '15 at 19:30
-
I've seen JSP pages represented in package diagrams. – belwood Jan 01 '15 at 19:35
3 Answers
2
JSP files are considered to be view files, they aren't actual functions/methods. Thus, they should NOT be included in UML class diagrams.
Tigerjz32
- 4,324
- 4
- 26
- 34
-
-
view would be 1 of the entities, forms would be another, urls would be another, models would be another, etc. – Tigerjz32 Mar 13 '15 at 20:08
1
I'm sorry, but I don't completely agree with the other answers, speaking from a purely UML standpoint. From that standpoint, a jsp file is an example of an Artifact, which is a type of class. An instance of a jsp file is an object, which has a particular «manifest» relationship with a Servlet (borrowing here from bdulac's answer; I'm no expert on Java Web stuff).
From the UML spec (Superstructure v2.0, p 193):
10.3.1 Artifact (from Artifacts, Nodes)
An artifact is the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a database system, a development deliverable, or a word-processing document, a mail message.
Further down:
In the metamodel, an Artifact is a Classifier that represents a physical entity. Artifacts may have Properties that represent features of the Artifact, and Operations that can be performed on its instances. Artifacts can be involved in Associations to other Artifacts (e.g., composition associations). Artifacts can be instantiated to represent detailed copy semantics, where different instances of the same Artifact may be deployed to various Node instances (and each may have separate property values, e.g., for a ‘time-stamp’ property).
And:
An Artifact defined by the user represents a concrete element in the physical world. A particular instance (or ‘copy’) of an artifact is deployed to a node instance. Artifacts may have composition associations to other artifacts that are nested within it. For instance, a deployment descriptor artifact for a component may be contained within the artifact that implements that component. In that way, the component and its descriptor are deployed to a node instance as one artifact instance.
Specific profiles are expected to stereotype artifact to model sets of files (e.g., as characterized by a ‘file extension’ on a file system). The UML Standard Profile defines several standard stereotypes that apply to Artifacts, e.g., «source» or «executable» (See Annex C - Standard Stereotypes). These stereotypes can be further specialized into implementation and platform specific stereotypes in profiles. For example, an EJB profile might define «jar» as a subclass of «executable» for executable Java archives.
And, a JavaWeb profile might define «jsp» as a stereotype extending «file».
Finally:
Changes from previous UML
The following changes from UML 1.x have been made: Artifacts can now manifest any PackageableElement (not just Components, as in UML 1.x).
While an artifact will often manifest a component, there's no reason to say that it can't manifest a class (which also "is a" PackageableElement). That's why they removed the constraint that artifacts could only manifest components. So, purely from a UML standpoint, a jsp file is a class, and so can be part of a class diagram.
Whether it makes sense to do so is another issue, but it's not something to dismiss without investigation.
0
All depends on the context in which you are using UML.
In UML distilled, Martin Fowler distinguishes three ways of using UML:
- Blueprint (UML is used in a software development process)
- Sketch (UML is used for a detail of a system)
- Executable UML (a use of UML where UML is the persistent source of the program, prior to the code)
Most software development processes (blueprint mode) won't allow you to include view components in your class diagram for logical reasons: UML is about OOP. This is also the case in executable UML, in other words this is what user1556242 said.
In blueprint or executable UML modes, the only UML diagrams on which view components are allowed to be represented in are the component diagram and the the deployment diagram: these diagram don't show object-specific features.
However, If you are in sketch mode, this is your legitimate right to include JSP pages in your diagram, but this should not be the view component form. In a class diagram you should represent classes. You should not represent the JSP page itself but its object form. A JSP is translated into a servlet class at runtime (see the Wikipedia article), in Tomcat this is done via Jasper.
