I am a beginner in cobol, and I'm passing an internship in big data batch processing, I am asked to do a class diagram in my project, but I have no classes, I only have tables with millions of records in DB2 that are being processed with cobol language, my question is : is it possible to make a class diagram in this situation ? (forigve my english)
Yes, it is entirely possible. An entity-relationship diagram of a database model is practically a class diagram.
Class diagrams are used with OOP languages. I am not sure how far did OO-COBOL go, but I have a feeling that it is not a common practice to use it in batch processing. Batch processing has always been mainly accomplished with NON-OO COBOL in COBOL shops or using C, C++ or JAVA on mainframes and UNIX, of course you could use any other suitable technology...
Class diagram shows classes (no corresponding non-oo COBOL structure for that) and associations between them. If each class represents 1 physical table and no OO features such as inheritance, a class diagram may be very close to an Entity Relationship diagram. However, a class is a code file in OO (or part of a code file) but in non OO-COBOL, a class does not exist and database columns are coded inside the some program of some name that is never shown on the Entity Relationship diagram.
Related
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD (Data Flow Diagram) and Class diagram ?And,
Which are the best diagram to build a software?
Thank you..
A DFD is one behavioral view of a system while a class diagram is a pure static one. A class diagram shows classes with attributes/operations and how they are connected. A DFD shows how data "flow" (i.e. class instances and/or plain objects are interchanged) under certain conditions.
What kind of diagram to choose depends on the objective.
DFD (Data Flow Diagram) is a graphical mapping of data structures and their interrelationships (storage, external sources, etc).
In turn the class diagram shows the entities, objects and their relationships.
I recommend first mastering the creation of class diagrams when building software.
I am a student and we have a Object-Oriented Project that we have to do to pass Object-Oriented course. My problem is to design the project. Teacher wants two different class diagram.Teacher said "One is high level, other one is normal class diagram." I know that high-level class diagram have detailed information such as attributes and methods. Additionally, I think high-level diagram covers normal diagram. What is normal class diagram? What is the difference between high-level and normal class diagram? I think that if we draw a high-level diagram normal diagram is redundant. Why Did teacher want normal diagram? I am confused.
There are typically 5 "levels" of design that one should think of, so that is where the "high-level" comes from. They are usually like this:
Software System - This is where you think of the software in terms of entire packages, or in terms of its subsystems.
Subsystems - This is the part where you ID all of the major subsystems, such as database, user interface, reporting engine, etc. This is the part where you define how each subsystem uses one another, and how they work together.
The first two are probably what your teacher meant by "High Level Design".
Classes - This further partitions the subsystems by classes. For instance, if you had a database system, you might have a class that manages the persistent connections, the metadata, etc. The way each class works with classes in other subsystems are also defined. This is probably what your teacher means by "class design".
Below that, you further divide each class into routines and internal routines, but I assume your teacher does not want you to get that detailed. However, for completion's sake, I will define them:
Routines - Design at this level includes dividing each class into routines. It is the "how" to the "what" answered in level 3.
Internal Routine - Design of the individual routines.
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.
I'm new to the MVC way of developing applications and for the most part am enjoying. One thing I'm a bit confused about is the use of the Entity Framework. The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table. A couple of questions:
Why would I define a separate class file for a specific table if EF is building all of the classes that I need in the background?
From some of the validation approaches that I've seen, they want to define validation logic in the class related to a model for a table. If I'm using EF, will I have a .cs file describing the model and a .edmx describing that same table (in addition to its associated tables)?
If yes, how do you connect the .cs file to the .edmx definition so that CRUD flows easily from the EF?
Sorry if these seem like easy questions but I'm just trying to get my head wrapped around these fundamental concepts. Too many examples out there use only a single table where in my business, I NEVER write an application that uses a single table. There are always multiple tables in relation to each other with foreign keys. Thanks for your prompt responses.
For a tutorial that shows the use of partial classes -- in a Web Forms application but for MVC the same technique would be used -- see Adding Metadata to the Data Model in this tutorial:
http://www.asp.net/web-forms/tutorials/getting-started-with-ef/the-entity-framework-and-aspnet-getting-started-part-8
From your comment "The EF usually (at least in my experience) defines multiple tables and relationships through the .edmx table." it sounds like you are familiar only with Database First and Model First -- for an introduction to Code First and an explanation of the differences, followed by a series of tutorials with an MVC example using Code First, see this tutorial:
http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Good questions, Darryl. Here are my responses to your bullet points:
Defining separate model classes that match the data models that EF creates is generally a good idea for the simple sake of separating your data access "stuff" from your business model objects that will get used throughout your app. Some people don't like this approach because it creates some amount of overhead when it comes to mapping your entities to POCOs but, if you use a tool such as AutoMapper, the overhead is minimal. The benefit lies in you creating a layer of separation between you and your (likely) evolving data model.
You could define validation logic in a buddy class (just a partial class that sits along-side your entity) but that would mean that you would be using that entity across your app and some would debate that that isn't the best idea. The alternative method, as mentioned above, is to create your own POCOs to mirror the entities that EF creates and place your validation attributes on the POCOs.
I mentioned this in the previous item but the way to do this would be to define buddy classes. Give EF buddy classes a Google and you should find plenty of examples on how to do that.
Just to add to all of this, if you choose to create POCO classes that mirror your EF entities, tools like AutoMapper can handle fairly complex relationships when it comes to mapping classes. So, if you have foreign key relationships in your data model, AutoMapper can understand that and map your POCO classes accordingly (i.e.: You have an entity that has a 1-to-many relationship and a POCO with a list of objects to mirror that relationship.)
I hope some of that helps...
Let's say I have two tables in a database: projects and users. I create two models, that extend Zend_Db_Table_Abstract: Model_DbTable_Users and Model_DbTable_Projects.
Now, is it a good pattern to create an instance of Model_DbTable_Projects inside the Model_DbTable_Users class ? In other words: is it OK to put any logic in this model, or should I create another class, that uses Model_DbTable_Users and Model_DbTable_Projects?
I use to put all the logic in models, that extend Zend_Db_Table_Abstract, but in large projects it can make code very unclean. So, can you give me any advice on models architecture(links on articles would be great!).
I was the project lead for the Zend Framework project through version 1.0. My contributions were mainly in the Zend_Db component.
I frequently advise that people should use the Domain Model pattern and avoid the Anemic Domain Model antipattern. Remember that a Table is not a Model.
Your Model is a class (extending no base class) for code that encapsulates your business logic. The relationship between a Model and a Table isn't IS-A, it's HAS-A (or HAS-MANY). The Model treats database persistence as an implementation detail. The consumer of a Model should have no clue about your database structure (this allows you to change database structure without changing the Model's interface).
I'm basically repeating the answer I gave to Models in the Zend Framework.
Here is some more reading:
http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html
http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
http://n4.nabble.com/Another-Model-Design-Thread-td670076.html