I have developed an online web application which uses JSP's and Java classes.
I understand that Java classes would appear on a class diagram but would JSP files ?
My answer is no.
Class diagrams can be utilized for different purposes, at different levels. Two very common usages are design and analysis.
1- Analysis class diagrams show the entities and their relationships and model your problem domain (no solution or technology involved)
2- Design class diagrams model your solution and may contain fabric classes. They are very close to your code. (your Java classes in this case)
Design class diagrams could have different levels of abstraction according to your need. It is very uncommon to include UI details in your class diagrams unless there is a specific reason for it.
Basically you have to make a decision on your scope, for example it is not very useful to include java library classes in your class diagrams unless there is reason for it.
Related
In my android app , i have a lot background classes. My question is should i represent these classes in classes diagram
It is a common mistake to think that there should be one class diagram with all the important classes of the system.
But this is not how it works. Each diagram is meant to convey the relevant information about a given topic. So you may very well have:
a class diagram with none of your background classes because the do not add any useful information to your domain model.
a class diagram with a couple of background classes, for example if you model say a GUI component and some background classes play an important role therein
a class diagram with only a set of background classes, because it could be useful to document those (you probably have such a diagram if you use one of these popular frameworks that comes with a class diagram in its documentation.
Can someone explain me the difference between class diagram during analysis and design?
So far, I understand that the class diagram of design would be the real class diagram, with all methods and attributes (ready to become code), but what about analysis? Do I have to do a class diagram for every sequence diagram? Do I have to add methods and attributes at the design stage already ? Or only connection?
The UML class model is produced and refined iteratively as the understanding of the system increases. There's only one model for your system, although different diagrams may outline different aspects and level of details of this model.
Typically you would start with the domain model based on the requirements (e.g. use cases, user stories, statement of work, user interviews, etc.):
Top priority is to get an overview. So the first sketch would identify the domain classes and how they relate to each other.
You would then enrich this initial understanding by outlining in the diagram the key properties and methods that are essential to the understanding of the domain.
You would then enrich the model with more detailed design diagrams as you design your solution. So you would add any classes required for the implementation (e.g.user interface classes, application controllers, persistence layers, etc.).
Design diagrams are used to get a shared understanding about the software structure within the development team. So they should be easy to understand (i.e.focus on important aspects and not necessarily be cluttered with too many details that would anyhow have to be implemented in code and quickly be outdated if you don't have an army of analysts to update the model).
If you'd use an UML tool able to generate code or if you are contractually obliged to provide all the details in UML form, you would further refine the model with a fully detailed implementation diagram. Attention: for scholar work it is frequent that the teacher asks for a design diagram but expects in reality an implementation diagram.
We have 3 major types of class diagram in Object Oriented Methodologies.
Class Diagrams in Requirement (Domain Modeling)
Analysis Class Diagrams
Design Class Diagrams
Main difference of these class diagrams is their Abstraction.
In Domain Modeling, we use Class Diagrams. BUT, we do not use any Inheritance or any Interfaces, or any preforming analysis on the classes. We just write so little attributes of classes (about 3 attributes). we don't write any methods of classes. WHY? because of Abstraction. Main goal of Domain Modeling is modeling the domain. And detect Which classes should be in problem domain of system.
In Analysis modeling, we use class diagram. Classes in analysis is more detailed than classes in Domain. But it is not the final specification.
In Analysis, we determine Analysis Classes. We can use Inheritance between them. We can write their attributes and methods in detail. BUT, this phase is done by System Analysts. (Not System Designers or Programmer). Their profession is both knowing the Business Logics and Software Techniques. So they can write analysis classes in more detailed than Domain. However, they can not write very detailed as System Designers can.
In the other hand, we can use some analysis patterns to determine our Analysis Classes. For example RUP introduce Boundary/Control/Entity pattern. If we decided to use an existing analysis pattern, we can use the guidelines exist in the pattern documentations.
The guideline of Boundary/Control/Entity about the abstraction of classes are in this reference. In this pattern we should write only attributes for Entity classes and write only methods for Control classes and write attributes and methods for Boundary classes.
However, In my idea, we can follow the guideline or not. We can write more attributes and methods for analysis classes. What is happening? If our System Analyst try to write more detailed attributes or methods, what's happening:
I think that 1) our system analyst is not system analyst. maybe system designer. 2) we don't need their details. It is just time consuming for analysis phase. 3) ONLY if our analysis and design team are the same, or we combine analysis and design (like Agile Methodologies) the details in Analysis can be logical and useable.
In Design modeling, we use class diagram, this type of class diagram should be the final specification and should contain all attributes and methods. This classes are not conceptual. we can use all OOD technologies, Design Pattern and etc.
Given I have two Java classes Foo and Bar, and Bar has a getFoos() method that returns a List<Foo>.
In Java, all classes extend the parent class Object. List is an interface that extends the interface Collection, which in turn extends Iterable. All of these are provided by the Java core and do not require programming. However, they have methods that can be used or overridden. Interface hierarchy may be necessary to be known, for example a method that takes an Iterable<Foo> will accept a List<Foo>.
When drawing a class diagram from these in UML, how do I do with the well-known classes (Object) and interfaces (List, and its super interfaces Collection and Iterable)? Do I have to draw them into the diagram as well? Can I skip them completely? Is there a special symbol for these (a cloud would feel great to me)? What about not-that-common classes that should be qualified (i.e. if it would be an java.awt.List and not a java.util.List)?
UML is not linked to any language, there is nothing in the norm about JDK classes.
A lot's of tools provide a profile with JDK classes already defined.
So you have to look in your tool if you get menu like "import profile" and look which profiles are available.
Two others solutions could be:
Define in your models the minimum set of JDK classes you need
Trying to write a java program to generate the XMI of JDK classes. Theoretically not so complicated, but the JDK includes JNI classes on which the introspection can not be used.
Your choice for how to deal with well-known classes will depend on how you plan on using your UML class diagram.
If the main purpose for creating a UML diagram is to communicate design details to a team, I would opt for not including well-know classes (not just from the JDK but also classes that are well-known in your context). The reason being that you want your message to be focused. Adding these well-known classes can quickly clutter your diagram while adding nothing to your message. For the same reason I typically exclude getters/setters and any information that is not essential to understanding the design. For classes that are not well-known I will include them because they communicate information that is not easily accessible to the team.
If your class diagram is going to be used in MDA, i.e. it will be used to generate a system implementation, then you have to include well-known classes.
i'm php developer using MVC architecture that i'm new to UML
i know use-case , class , object , activity, sequence diagrams but i don't know for modeling a application where i should start.
i know use-case and class diagrams are structural diagrams and activity and sequence are behavior diagrams
but my questions are:
1. for modeling a app when i should use use-case diagram and when i should use class diagram?
2. does class diagram has abstract concept? because when i'm developing web app i have some controller and model or view also several classes that i use for different purpose (like insert data to database - validate form inputs and so on) but they don't look like to examples of class diagram that i'v seen until now so my question is class diagram is used for show concept of our system and it doesn't need to generate real class code form it ?
for example modeling a ticket reservation that may have some classes like this:
but we don't write class codes like this and it can be different in programming but for view the concept we are using class diagrams . is it true ?
Use-case diagram is usually used for representing the business of the project, indicate who(actor) are going to utilize the system and what services(cases) does program provide?
The class-diagram is used for specifying the whole system structure, but there no code and exact behavior will be provided by the class, generally developers don't specify the exact behavior with each module in-detail.
for example, consider a simple login module. in use-case diagram, we just mention that user logins into the system.
In class diagram we specify the possible base classes are needed, in other word we apply the architecture (we are planning) basis.
In sequence diagram we focus more on what is going on each method(while this is not necessary).
In fact UMl is used for representing the system as abstract, not the exact(in-detail) functionality.
for example I pass the above class-diagram to a developer, and tell him about the detail login process as a separated document.
I have an assignment that states the following criteria:
For this view you may use a truncated version of
your Design Class Diagram (DCD) including
only the architecturally significant classes.
For context, this is for the Logical View of a 4 + 1 Architectural View. How does a design class diagram (DCD) differ from a regular class diagram? Is it the UML diagram without the functions or variables included (i.e. just the names of the classes and their interactions with each other)?
Most of the time, people model their code. That's good! In that case, class diagram modeling is used to graphically represent the structure of (object-oriented) classes: class, method, attribute, annotations with stereotypes. Imagine all the JPA, Spring, whatever annotations in the class diagram of a JPA-J2EE based architecture...
As it's said above, the "design class diagram" should only design your domain model, from an architecture level. What are the basic entities your structural system rely on?
No details about the programming language, no "dto", "dao" or technical stuff like that.
Here's a good example I use: online shopping cart domain model. It only contains the architecturally significant classes.
HTH, Tom
Still its amibigous to understand. The main difference between analysis class diagrams and design class diagram is the analysis phase focus on designing a class diagram without concerning about the implementation detail. where as, desgin modelling concern with the implementaion and architechture since, it the high-level static view of the system.