I develop similar calculation packages for different clients (Bob, Rick, Sue, Eve). The calculation packages consist of several calculation modules (A, B, C, D, ...), which are organized in a "Chain of responsibility" pattern. Assembly is done with Abstract factory.
As a lot of code is shared between the calculation modules of different clients, they are organized in an hierarchy:
ICalcA
|
AbstrCalcA
| |
AbstrCalcAMale AbstrCalcAFemale
| | | |
CalcABob CalcARick CalcASue CalcAEve
(same hierarchy for B, C, D, ...).
Now release management dictates, that I organize the source code per inheritance level:
Project: CalcCommon
[CalcA]
ICalcA.cs
AbstrCalcA.cs
[CalcB]
ICalcB.cs
AbstrCalcB.cs
[CalcC]
...
Project: CalcMale
[CalcA]
AbstrCalcAMale.cs
[CalcB]
AbstrCalcBMale.cs
[CalcC]
....
Project: CalcBob
[CalcA]
CalcABob.cs
[CalcB]
CalcBBob.cs
[CalcC]
....
Project: CalcFemale
....
For Bob, I release CommonCalc.dll, CalcMale.dll and CalcBob.dll.
Now this is all good, but with many modules, helper classes, and so on, it is very cumbersome to work within the same module hierarchy. Closely related classes (e.g. ICalcA and CalcABob) are far away in the solution explorer. No one on my teams seems to find anything without searching for the class name -- if he can remember it. Features tend to get implemented in wrong or multiple hierarchy levels.
How can I improve the situation?
I was thinking of creating one project per Module and hierarchy level (Projects: CalcCommonA, CalcMaleA, CalcBobA, CalcRickA, CalcCommonB, CalcMaleB, ...), and grouping them via solution folders.
I just found out that the new search bar on top of the solution explorer comes in handy for this.
Step 1: Make sure all classes related to Feature A contain "FeatureA" in their class name.
Step 2: If working in the FeatureA hierarchy, enter "FeatureA" into the search/filter bar.
This will display just to the classes of this particular hierarchy, just as required.
Related
We are required to make a package diagram for our senior project. Since our project uses MVC patter design, we created an MVC class diagram, now, our problem is in creating the package diagrams from our class diagram.
Is it possible to have packages with MVC at the same time? so it would be something like this:
Package: Account
Account Model
Profile Controller
Registration Controller
Profile View
Registration View
These are the controller that cannot exists without the Account model, so I included them.
Thanks in advance!
Usually it goes vice versa - class after package.
Are you sure you need the package diagram? What you show, are not packages, but components. Packages are things that hold together only syntactically, and components are things that hold together really (not necessarily syntactically)
If yes, create packages according to the functionalities, as you named them.
As a stage two, create 3 subpackage for every package, according to the levels of MVC model. (sometimes there will be more or less than 3 of them)
Make 2 diagrams:
of large packages - there you can also show their info exchange on the conceptual level.
And of small packages - there put their names in form parentPackagename.thisPackageName. Here you can show the visibility levels of different info. Very probably, that on this level you'll need to divide the huge common diagram into understandable smaller ones.
I'm making a leave management (HRM) website. I'm using codeignitor HMVC to build this. Following features are included in this site:
A table to display a summary of leaves.
A table for leave types like annual, MC, urgent, other...
I was thinking to create two modules for leave_summary and leave_types, but my friend told me it is useless.
According to HMVC architecture we are trying to create self contained modules for reusability. If I'm creating a different module for leave types, I should be able to reuse it and module itself needs to be self containing. But I can't use leave_types module anywhere else.
My friend asked me to put all the leave related stuff in one module called leave. This sounds strange to me as I found lots of examples people are trying to separate things out.
Do we only need to separate the modules which can be reused in the future (ex: login module, image_gallery module, profile module) and keep all others things inside a one module?
(according to the above example I have to keep everything related to leave in a one module
ex: leave_type, leave_requests, leave_summary will be placed inside the leave module)
What are the benefits I will get, if I separate the leave_type, leave_requests, leave_summary etc... into separate modules?
Will I be able to reuse them? If so How?
In HMVC model classes and other assets can be exchanged among the modules, so how can I call it a self-contained module or a separate entity as it is depending on another module?
(ex: I have to call leave_type module's model class inside the leave_summary module to show the leave type name in a table.)
I'm little lost here. Please help me to understand. Thanks a lot!
As i work lot of MVC projects. And I am agree with your friend.
May times this question arise when i used join that i have to choose in which one module i should go for write query. If you write in one model may next developer will write in another one model.
So according me it is best to keep same type of tables which are handling relation and using for same behavior use this approach like leave model, profile model etc.
I'm using Acceleo-MTL to generate Java classes. How do I get all my abstract methods from my abstract superclass?
To get simple operations and interfaces, I use this:
[comment]Operators[/comment]
[for (o : Operation | class.getOperations())]
[o.generateOperation()/]
[/for]
[comment]Interface Methods[/comment]
[for (interf : Interface | class.getImplementedInterfaces())]
[for (o : Operation | interf.ownedOperation)]
[o.generateInterace()/]
[/for]
[/for]
Does there exist a getter Method for Abstract methods like you have getImplementedInterfaces() for Interfaces?
This all depends on your metamodel and how to navigate it. IIRC, Class.getImplementedInterfaces() is something that comes from UML, so I'll assume that's what you're using.
Furthermore, what you seem to be trying to do is "retrieve all operations for a given classifier, including inherited ones". There should never be any reason to navigate upon the super-classes and interfaces hierarchy yourself for such needs. In UML, this is done through Classifier.getAllOperations(), which means that you can do everything through :
[for (o : Operation | class.getAllOperations())]
[o.generateOperation()/]
[/for]
If you absolutely need to iterate over the interfaces and super-class(es) yourself, remember that you need to recursively navigate the whole hierarchy : the super-classes and interfaces of your class, the super-classes and interfaces of the super classes of your class, the super-classes ... until the root(s) of the inheritance tree. You'll also have to handle UML's multiple inheritance capabilities and thus solve the potential ambiguities it brings. For that, you'll need to familiarize yourself with the UML model. For instance, retrieving the super-classes is done through Class.getSuperClasses(). Determining if one of these super-classes is abstract is done through Class.isAbstract()... and so on.
A side note that could help you : you can import the UML metamodel in your workspace to have a quick overview of its concepts and how to navigate through it. For this :
Use File > Import...
In the pop-up, navigate to Plug-in Development > Plug-ins and fragments and hit Next
Nothing to change on this page, hit Next a second time
In the filter area, enter org.eclipse.uml2.uml
Double-click org.eclipse.uml2.uml in the left panel so that it appears in the right one.
Hit Finish
You now have a new project in your workspace, named org.eclipse.uml2.uml. You can open the org.eclipse.uml2.uml\model\uml.ecore file to see the UML metamodel.
currently I trying to do something a bit tricky which I don't really know if it's possible to do.
I have a class project and I want to divide it in two sections, "Core" and "Client specific developments". And my client wants the source code of this project but I don't want to deliver the source code of the "Core" section, I just want to give him the source of "Client specific developments".
So to demonstrate a practical case let's imagine that I have a partial class named "User" that have two methods "CreateUser" and "CreateUserForClientSite". So "CreateUser" method will be located in "Core" section and "CreateUserForClientSite" will extend "CreateUser" with specific requirements for my client site (remember this methods may NOT be static, so C# 3.0 class extend feature is pointless in this case). If I have the "Core" section in dll can I extend a partial class present in the dll?
Now let's imagine another scenario. What if "Core" have methods that depend on "Client specific developments" classes, and the other way around? Since I can't do circular reference between projects, how can I manage that (is possible)
Thanks
Regarding the partial classes - you must have all the parts of the partial class available at compile time. You just split definition of a class in several files, but it is still a type that belongs to one assembly.
Thus you cannot compile dll with one part and then reference that assembly in another project and add more methods to the partial class.
I suggest to replace partial classes with inheritance in your case, if possible.
More on partial classes in msdn (look at "Restrictions" section).
Regarding the circular references - you'll have to redesign your object model if splitting into two assemblies leads to this problem. Usually, this indicates flaws in the model that should be fixed anyway.
You can define interfaces in the core assembly to break the circular reference. And implement the interfaces in client specific assembly. Take a look at this article for example - How to get rid of circular references in C#
So thanks to the Visualization and Modeling Feature Pack , I can build a uml model diagram and generate a bunch of classes.
But what now? Presumably, my developers will add code to those classes. Useful code, valuable code, and as the templates themselves indicate:
// Changes to this file will be lost if the code is regenerated.
So what is the best solution here? Can I make the modeling project reflect changes to the actual classes? Should I generate partial classes? Modify the default templates to read class files and not auto-generate anything that has been modified? Should I tell developers not to edit model files under pain of....well, pain?
Thanks for the tips.
As far as I know, this is really the key reason for partial classes in the first place. The custom code goes in one file, the auto-generated in another.
You could also create classes derived from the generated ones, and put any changes in there. I also agree with above poster that partial classes could be the way to go.
Although the tools generate basic skeleton classes out of the box, that's really just a starting point. You can easily adapt the generator templates to create your own stuff. Different people want to generate different code from the classes - some even generate XML or SQL. And yep, in C#, partial classes are good to generate, so's to keep the hand-written code separate from the generated bits.
It's good to put lots of extension points in the generated code, where you fill in the details by hand code.
Another neat idea is "double derived": from each UML class, generate a base class and a derived class. The derived one has only constructors. The base class has any methods you generate. So your hand code can easily override generated methods where you need that.
There are several options in the tool and recommending what is best is hard without knowing your scenario. Partial classes are great for some, but not all applications. If you want your UML class to generate a partial class, you can set it's C# stereotype's property to "Partial" and it will do so, and custom code can then be added in a partial class that won't be overwritten. If you want to prevent code from being overwritten, you can do this by setting the overwrite property to False on the template binding that corresponds to the package you are working on. This lets you set your extension code to be in a package that is not overwritten, while your model mastered code is overwritten with the latest model changes. Finally, if you want your code to be the master for your model so it always reflects the latest code, then you can reverse engineer your code by using the architecture explorer to select your classes and then dragging them in to a UML diagram. So for a given gesture, either the model is the master or the code is the master. In this version, we did not implement automated merge capabilities between the two.