I am implementing a class diagram for an application related to teachers and students as an assignment. A student can have many teachers.
I will implement a menu in coding. Should I add menu and interface as classes?
If yes, how should I link all these?
What can menu and interface contain?
Could I say: menu has settings and teachers page, which has all teachers profiles in it?
A class diagram with only classes belonging to the domain of application (e.g teachers, students, classes, ..) without any of the app's internals (e.g. UI related classes) is called a "domain model". Its goal is not to document all possible classes used in your app, but to focus on the domain knowledge, independently of how the app is structured or implemented. Such domain model would stay the same if you create a mobile app, a text based terminal application, or a voice controlled app.
On the other side you may also want to give insights on how your app is designed, i.e. using menu classes, database connectors, etc... This is also fine. It's up to you to decide what is the purpose of your class diagram and what you want to show with it. The only thing that you should avoid is to have one huge diagram with everything, because it'll be too complex to explain anything. Better go with several class diagrams focusing on different aspects of your design.
One thing that may help if you want to combine in the same diagram classes with very different purpose, i.e UI classes, domain classes and business logic, is the Entity-Boundary-Control stereotypes, to help to understand what class fulfills which technical purpose.
Related
I'm working on an automated tests project, where I create UI tests with Selenium/Selenide in java for a web-based media player, that is then integrated in other products of my company. However, there was a UI for that Player (as a React component) in the application my team is developping before there was a UI for the Player itself, in standalone. So, basically, I have to redesign the code that I had for both the application and the standalone Player: the goal is to create the code in the Player package, to then import it to the application test project.
The problem here is that, in the standalone version, the Player HTML code contains a shadowroot, and the Player React component in the main application does not. This means that I have to use WebElements in the standalone version, whereas I am to continue using SelenideElements in the main application test code (to be able to deal with some particular interactions that occur in the main application and that are not possible in the standalone Player).
Normally, for each "part" of the Web page, I create a "Client" class that contains the methods to find the elements, and then to perform the interactions with them and/or verify their state. Since the two UIs have the differences I explained above, I imagine that I will have to have two different sets of Client classes. I was thinking of doing something like creating another class or an interface to try to find the shadowroot element, and, depending on whether it was found on the HTML code or not, initialising one of the two sets of clients.
So, my question is, how can I overall structure all of this in terms of classes/interfaces/methods, so I can have as little doubled code as possible in both Client sets?
Any help is welcome, even if it's just to show me that I'm thinking about this in the wrong way.
Whenever I hit such a case
Since the two UIs have the differences ... I will have to have two different sets of Client classes ... creating another class or an interface to try to find the shadowroot element, and, depending on whether it was found on the HTML code or not, initialising one of the two sets of clients.
and especially for as little doubled code as possible in both Client sets, in my experience Strategy provides quite suitable solution. It defines a family of algorithms, encapsulate each one, and make them interchangeable. Also lets the algorithm vary independently from clients that use it. So, you may think for the algorithms to be your test steps and the clients are the apps loaded.
I am new to android programming. I often see that programmers create packages as collection of activities, fragments, adapters, etc. To me it seems more intuitive to put all java code required for an activity/screen in one place. For example: For home screen, I will keep the activity, fragments, adapters, custom views, etc all at one place.
Is there is any definite reason the the general practice or is it just a traditional practice ?
This has to do with creating components, reusable objects and code maintenance in a codebase as it grows. Your approach will work for a small application, and there is no rule against it. However, generally creating package/file structures according to the recommended and common approaches makes it easier to make modifications to code and work with others on the same project. Consider the following:
If you have many Activities spread across many packages or folders, then someone tasked with changing the UI will have to traverse those packages. That makes it difficult to identify UI patterns that could be used across Activities and even harder to use those patterns, since you will need to implement them in each package/folder.
This also creates a problem seeing less obvious patterns in non-UI components like data object models, view controllers, etc. For example, if you need a "user" object in two different Activities do you create 2 different objects? This is not reusable code.
So let's say you decide to reuse the "user" object so that you only have 1 class. Then do you sub-class in the other packages that need it in order to follow your pattern? Then if one UI element needs a new method, do you implement it in just that place? Or the base object?
Or do you make the "user" object public and reference it from other packages/folders? If this is your answer then you will begin to create objects in places based on the evolution of the code, instead of based on logic or ease of maintenance. Among other things, this makes it very difficult to train a new person on "where everything is" in your codebase. The "user" object will sit in one place, and then the "user account" object ends up where it is first needed, but not likely to be with the "user" object.
As a project grows to hundreds of classes, I think it is obvious that this approach becomes unmanageable for many applications. Classes will appear in packages based on the UI requirement, not based on the function it performs. Maintaining them becomes challenging.
For example in the case of Lollipop to Marshmallow, Apache http became deprecated. If you had this dependency scattered throughout your project, then you will be looking in a lot of places at how to handle this change. On a small project that might be fine, but on a larger project if you try to do this while other development is taking place, this can become a real mess since you are now modifying across many packages and folders instead of in only a few locations.
If, however, you have a Data Access Layer or Model Layer components that encapsulate the behavior in one or several folders, then the scope of your changes is easier to see to those around you. When you merge your changes into the project, it is easy for the people you work with to know if other components were impacted.
So while it is not necessary to follow these guidelines (especially for small projects), as a project grows and several or many people become involved in the development, you will see variations but the general practice is to group by purpose or function rather than group by UI / visual component. If you start off with some of this in place, you will have less work later to deal with the change. (However, starting with too much structural support early in a project can put the project at risk of never being completed...)
Several answers provides links to the guidelines. I hope this answer helps to explain why those guidelines exist, which I believe is at the heart of your question.
Is there is any definite reason the the general practice or is it just
a traditional practice ?
Yes. In my current application I have over 50 custom UI views and a few activities. At least 10 singleton controller and a lot of database model. So to not lost in the project, I'm using a tidy structure like this:
Activity
Adapter
Controller
Native
Model
-Database
-Rest
Ui
I suggest you to use this structure.
There are no official rules, well maybe best practices which I have not in mind.
I so we get now a opinion based answer:
I use the package names for grouping classes to a logical topic like adapters, activities, etc.
If you want another structure do it like you want, just it could confuse other devs.
Keep in mind that the package name should be unique so you should use a prefix like a domain you own or you are allowed to use (in reversed order of cause).
Check also this link where are some more ideas pointed out: http://www.javapractices.com/topic/TopicAction.do?Id=205
The first question in building an application is "How do I divide it up into packages?". For typical business applications, there seems to be two ways of answering this question.
Package By Feature
Package-by-feature uses packages to reflect the feature set. It tries to place all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application. It's also interesting to note that, in some cases, deleting a feature can reduce to a single operation - deleting a directory. (Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)
Normally the activities are places in the main package and fragments, adapters, utils, models in their own packages like fragments in fragments packages and ISODateParser class could go into utils package.
You can find more about it in the Android Best Practices guide which contains best practices for android.
The guidelines about which classes should be placed under which packages are discussed under the Java packages architecture heading in the guide.
Hope it Helps!
I have encountered with this problem often. Couldn't think of a way to how to face this. Now I got this excellent forum!! I'm sure experts here will help me with this.
This is not a problem about a specific code segment like thing. I am capable (as I think) of doing some advance projects in java. It means, simply, I can finish the project to give the exact result.
But the problem is, though I can finish it some how, I'm not satisfied with the management of the classes etc. Actually I don't know how to properly manage it. I'll explain considering the project I'm currently working on (I'm not a professional coder, this will be for my self learning).
I'm working on a database management system (MySQL + Java). There I'm hoping to implement several features there. The flow will be, roughly, like this.
1. Login
2. Main window
Main window will be like this.
In the left panel you can select what you need to do.
Eg.
*. Add some entries to the database
*. Search database
*. Other..(will be add later)
Can some one please tell me how to manage all those things, two frames and several panels.
What I've done is like this.
I've written a managerClass which has the main method. Then It'll call loginFrame first. After validation, loginFrame calls a method in managerClass, to load mainFrame. But I keep a reference to the managerClass in all the frames, panels etc.. as I save all the required info in managerClass, like user name ect..
But when modifying and debugging, things become really really difficult. As I haven't done thing according to any specific rule. I'll have to modify almost all the classes to do a slight modification. I've though a lot and sea
From what I can understand of your application, your main issue is the coupling between your components and the different layers of the application (presentation, interaction control, domain logic). I would suggest using two design patterns (or styles) that may help here:
Model-View-Presenter: separates the Model/Domain logic from the presentation (View) from the logic of controlling user interactions. I've used it recently in a large application and I've found it really helps to separate concerns in a clean way and makes testing much more simple. Please don't confuse it with the Model-View-Controller model, which is close, but have many issues. There's a nice article by Martin Fowler describing these two patterns
Adopt an event based interaction between your components. Instead of the Login frame calling the Manager class, make it fire an event ("user authenticated"), which is handle by the interested components. For example, you may have a small user account details panel in the main window which is not displayed until this event is triggered. Unfortunately, I'm not aware of any event framework for plain Java (which I suspect if the what you are using for development) The one I use is for Google Web Toolkit.
I have an enum that has two dependencies. These two are in different projects (Im coding in Java). I want to show this dependency ina UML diagram but how can I show what projects these classes are from? (I know for packages you can put it like this: Package :: pkgName).
Any ideas would be helpful. Thanks
What tool are you using?
In Rational Rose, if you this structure:
Folder1
|___Class1
Folder2
|___ClassDiagramX
and the ClassDiagramX shows Class1 then you'll see a small "stereotype" like note indicating "from Folder1" in the box representing Class1.
That should be sufficient.
There are other options using fancy-colorful-notes, but I don't care so much for them.
--edit--
Without knowing the tool I can't really say what you can and can not do. From UML pov, I don't know of any defined convention, so whatever conveys what you wan to can be used. Class diagram is a representation and does not affect the meta-data of the class (e.g. which project it belongs to). So as long as the "class" is in the correct package, it's doesn't matter how it's "shown" in the class diagram.
E.g. in the class-diagram you can put up 2 big squares in the background showing / grouping classes from each project and dependency arrows running across these groups.
OR
"add the line" if that's possible in your tool.
If you use Eclipse and java then you have a feature which allow to join two different projects. I mean open the package explorer and click on the project name then select join, or merge with I don't really remember the exact title of the menu but it is easy to find.
Once your both projects have been joined your can create a class diagram and just drag drop inside the same diagram two classifiers coming from different projects.
Project in the sense of "a set of planned activities and deliverables, with common goal" can not be reasonably encoded in UML.
Project in the sense of "a set of related files and metadata that allows an IDE to compile and run a program" is out of scope for UML, as this is a development environment artifact and not application design artifact.
For example, you can decide to use multiple projects for each module of your app or a single project for all modules. This will not change your design, only the instructions for the IDE - it's even possible that different team members have different project configurations, especially if some use Eclipse, others IntelliJ IDEA and some EMACS.
On the other hand, if you still want to denote logical sets of classes, you do have options - the formal way would be to use tagged values. Alternatively, I often use colors (for example, green for public API, yellow for extension points/SPI and red for implementation classes; or blue for low-latency multicast component, green for guaranteed messaging components).
You may also use a separate component diagram, showing which class belongs to which component (remember not to build uber-diagrams, but instead aim for simplicity and showing only the relevant facets of the design)
This was a generic advice, but the answer you need is very context-specific. I can get more concrete if you can describe in more detail what are the classes in question, what are the projects (how do you delineate between them) and the overall architecture of the system.
In a layered architecture, you have a presentation layer, logic layer and data layer.
So far, I've been grouping classes into domain, service and dao packages. This represents the model with POJOs/JPA Entities, the business logic and data access layer.
I suppose the domain and services could be grouped to form the logic layer but that leaves a question mark on the presentation or UI layer. Are there any conventions, even unwritten, in terms of grouping classes into packages by their nature in this layer? Or is this left to the appreciation of whoever is leading a project?
As an extra indication, I'm experimenting with web applications at the moment and using a "servlet" package to group servlets and a "web" package for ResponseHeaderFilters, ServletContextListeners and utility classes. I would be interested to hear how things are done with a desktop application.
I've never heard of package naming conventions with regard to the architecture. The only convention or 'best practise' I know is that your package names should start with a unique pattern, most often formed of a reversed domain name (like com.mycompany) or so. Just to make sure that you do not add classes from different libraries to the same package (namespace) which might lead to unexpected side effects.
But anyway, it's increases readability if you name the packages after the tier or usage. I've seen a scheme like the follwing which I personally liked because it was easy to find and identify the classes, and easy to extend:
com
.company
.product
.module1
.server
.function1
.impl
.client
.function1
.common
.function1
.impl
I've never really seen too much of an issue with this.
If you look at the class diagram for your project, you will almost instantly see logical groupings, and the tree structure of the packages tends to map easily to any grouping you need.
using the reverse domain name system (com.company.product...) you will never find a collision even within your own company.
Using Andreas_D's example, under .server and .client you may actually have an additional 3 or 4 levels of packages with dozens or hundreds of individual packages inside it if your project is large enough to warrant that.. but the structure at that level tends to come out of your product design.
Note: This similar question seems to be getting some good descriptions how to use packages: