Over the years, I've investigated a lot of ways to use code generators and MDD. I've always felt that something is lacking: Patching and changes to the model at runtime.
Patching: If you have a code generator, all your classes should look the same. Now you have a single exception. All code generators so far would require that I modify the template or the template engine to make this work.
Wouldn't it be better if I could apply patches to the result of the code generation step to fix the exceptions?
Well, it depends on how you build your model. If fact, it depends on what code generator you are using, its approach, and what it lets you do.
Creating an exception to a rule (model) is more or less against the nature of MDD, unless the applied modeling approach allows you to add exceptions as modeling entities.
I think ABSE is the only modeling approach that accepts "custom code" as a first-class entity, just like a text or an integer. If you create a template that contains a "CustomCode" parameter, you can later add your exception code only when necessary, without breaking your model rules. This can be used to add or replace code. You just need to specify it in your template.
AtomWeaver is a free implementation of the ABSE modeling methodology.
MDD doesn't work because it is based on a view of the domain and not the entire domain. I mean that usually MDD take an XMI in entry coming from an UML diagram. The problem is that this diagram is only a view of the domain and therefore you have many alternative and the real world is a mot more complex specially at deployment stage.
The only company which has provided me real value in my project was Omondo with EclipseUML. EclipseUML doesn't try to do MDD but create UML at diagram level live synchronized with code. Deployment is made using stereotypes which are added in the java annotation in the code. I can therefore model and if I add deployment stereotypes then my application can be deployed immediately/ If I manually change my code, then my model is refactored and all my views updated. If I want to add a documentation then I just add notes in the metamodel. These notes are live available when I click on each element. No more printed documentation needed because live navigation, dynamic views creations etc...
My EclipseUML model is always up to date, and I can deploy it immediately because Java annotations are lived synchronized between the model, the metamodel, the diagrams and the code. Really cool :-) :-)
Related
I read there are 5 disciplines in a unified process, Requirements, Analysis, design, Implementation, and test.
I've basically done the following UML's and I'm trying to add an explanation of how I adhered to the unified process. I did the following UML's for my project: Use case, Analysis class, Design class, Activity, Sequence, Deployment, state machine, and component.
I can already tell based on content that the use case falls into the categories of requirements. Analysis class falls into the category of analysis. Design class in design. But what about the other 2 disciplines? I am having some trouble understanding unified process. But if I were to assign the UML's to a discipline, what would they be assigned to.
Implementation will be a mix of class and component and deployment diagrams. For test there's nothing in pure UML. You can create your own profile for it. Basically it ends up in sort of use case diagram for business with traces to requirements being marked in some way. Unit testing can trace classes to requirements. This is a wide open area where you can write more than one thesis about.
I have done a web site project in PHP using mySQL at school, which was not object oriented but that was in a manner on which I want to display my content. Then I changed the same project into object orientated classes where I use same CRUD queries in functions of that classes and they interact with a DBWrapper class. Or can say, I just cut the php content and pasted it into the functions and and call that functionality through object. that all was done without documentation. But now i am making a project in .net with documentation how ever its a web based app actually and i have the idea of getting data from database trough queries and o of course c# is different but CRUD is something which is similar in any language. so as i had decide first this thing will display and from thing the next this thing will display etc. about codding than how should i know my class diagram is the same as what i am getting and what that actually is. because i will connect both classes as i wnt to display . and plus is Do we write object of other class as an attribute of second class if that is going to use in it.
Most class diagrams I've seen and made include only the business model entities. Most of the time UML diagrams are used to communicate and document the workings of the system. I like to think of them as pseudo-code.
Please refer to this other question as well: https://softwareengineering.stackexchange.com/questions/190429/what-classes-to-put-exactly-in-a-class-diagram
However, if you feel your implementation ended up with a lot of helper classes then it's probably good to review your system's structure to make sure you are coding "object oriented". Actually making the class diagram is supposed to help you realize what you can improve.
I suggest you also take a look at design patterns. This link might be useful, as you mention experience with C# http://www.dotnettricks.com/learn/designpatterns
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.
I am very confused on what are these "components" should be. I am just starting with UML by the way. I don't know what components should be used or be place in the diagram. I've searched for definitions about these components and they are very hard to understand. Can you please explain it in a very simple way on what these components should be?
P.S.: This component diagram will be about a website. A planner website.
I can't post what I had in mind because I am a new user and new users aren't allowed to post images.
The way I think of them is as a large, logical, chunk of the functionality of a system; a bit like that which might be found in a single library or a .jar file. They tend to be associated more with software intensive systems distributed over multiple nodes (computers) and locations. They idea is that they interact, mainly, through well defined interfaces and that they can be replaced or "swapped out" with another component that will do the same job. An example would be changing to a different database management system, or updating some hardware drivers.
Components are used most in component and sequence diagrams.
I believe there is a debate as to what the real the differences between components and classes are. Both are specialisations of the concept of a classifier in UML
In your case —without knowing much about the specifics— you might have the following components with interfaces between them:
a web client component
a business/problem logic component or components
some sort of data management component.
At the end of the day though, you use the UML in whatever way works for you. A simple software project might not benefit at all from using component diagrams. It's up to each project team to define what context and level of abstraction they are working at and choose diagram types accordingly.
Im new to subsonic and generally this was of programming, i usually develop from a rad perspective so using the visual studio dataset designer, but i wanted to start looking at developing n teir approach.
Ive never used a business logic layer, (naughy) normally my code behind takes care of validation so to speak aswell as general page level validation.
How can i generate my business logic, do i create a partial class of one of my classes and then add the business logic into this? and how would this look? just so i have an idea.
Any exmaples or advice would be greatly appreciated.
Thanks
Dan
The big gotchya with SubSonic is that it generates classes from database tables, there is a 1-to-1 correspondence between the two. That makes the classes SubSonic generates quite unsuitable for use as business objects, because it would tie your business layer very directly to your database structure. This is a bad thing (in nearly all scenarios that come to my mind, anyway).
SubSonic is a query tool and little more. It most certainly is not an ORM.
With that in mind, I believe the correct way to create a Business Logic Layer is to write your own business classes, and write Repository classes to manage loading and storing the data. But use SubSonic only internally to the Repository classes to handle the actual persisting of your data to the database.
If you use the SubSonic generated classes throughout your project you will find you are most likely doing it wrong, and the first significant change to your DB schema will illustrate that nicely (or .. not nicely).
In fact, I would recommend quickly moving into learning a real ORM like NHibernate or Entity Framework. They bring you much farther down the Happy Path, whereas SubSonic still requires one to do much of the Data Layer implementation themselves.