In this unit, you have created a class diagram for a package delivery system, along with all the other participants in this course. Each of you probably has a different class diagram derived from the same narrative descriptions. Can all of these be correct? When evaluating class diagrams, what can we look for to asses that it captured the necessary data requirements? Parts of any assessment will be subjective, but in this discussion, we should explore the objective methods of evaluating these models.
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Even if class diagrams differ, we can review the class diagram to ensure it has high cohesion, is loosely coupled, protection from variations in the future, indirection, and each class has a clear responsibility. Going further into evaluating the diagram involves reviewing that the types of associations make sense in relation to the classes. We should not have unary associations that are not logical and pay special attention to any ternary associations, as these are rare. Assessing the types of association can help capture object responsibility and ensure they meet all data requirements.
We should also ensure the multiplicity for association relationships make sense related to the minimum and maximum constraints. For instance, we know that a customer always places zero or more orders so we should not see class diagrams that show the multiplicity for this common example as otherwise. In addition as best practices, when we see many to many relationships there should be inclusion of a helper class. Assessing the multiplicity can help make sure we have not forgotten any attributes/requirements that come from things like a helper class. This helps with indirection and lessening coupling when evaluating the models.
Lastly, making sure all relationships are accurately portrayed (e.g. association, whole part, and generalization/specialization). This will help to ensure the goal of loosely couples and high cohesion are achieved. While the class diagrams will differ, as long as certain generalizations, best practices, and syntax hold true they can all be “correct”.
Hi Iyana.
Great comment. I agree with you. To make sure the Class diagram is correct, we must make sure that the types of associations make sense, that the multiplicity for association relationship makes sense, and that the relationships are accurately portrayed. Good points
I agree that multiplicity is an important factor that has impact on the diagram. The diagram should make sense with the description of those factors. and yes all diagram can be correct as long as they make sense and fit with narrative.
Hi Iyana,
I think you bring up some great points of how we can assess and evaluate class diagrams objectively. Furthermore, as you mentioned, many class diagrams can be correct even if they look different as long as they use correct syntax and display the cases correctly.
Hi Iyana,
You provide great points. Multiplicity is the important one in the class diagram which I didn’t recognize when I was thinking about the question. It is necessary for understanding the relationship between two classes.
Thank you! Multiplicity plays a key role and can help us check whether we have forgotten any attributes/requirements. For example, as a best practice, when we see many to many relationships there should be inclusion of a helper class. There may be additional attributes within the helper class that we had not originally thought about.
Also, I think the most important things is to identify the relationships between different entities.
Thank you for your sharing. You have a good example. When define the relationships with each entities, people also have different ideas, so it will have many kinds of results, we could not say whether it is true or not.
I believe despite the fact that we would all probably have different class diagrams they can more or less be correct. They don’t all have to look alike as long as the associations make sense. We must make sure the relationships, and the minimum and maximum constraints make sense in the context of the narrative description. I.e. One customer can place one or more order, so we know the multiplicity in this case should not be anything else than that. Even though the class diagrams might differ, they can all be correct as long as certain association, relationship and syntax hold true and make sense
We cannot make all diagram look the same. people have different preference of the layout for sure. If the classes, multiplicity and relationships together made up a diagram that make sense, this diagram is correct.
And you also mentioned syntax, that’s a good point, the syntax should be proper as well.
I think your point sums up the idea very concisely and wholly. Different class diagrams can be correct as long as they have certain qualities that are the same.
I agree with you. The class diagram may be different from person to person, but it is hard to say if the diagram is all correct or wrong. If they make sense for the purpose of the diagram and using proper syntax, I think it can be a good class diagram.
I agree with you, because it is difficult to determine these class diagram are all correct or not. Everyone has different thoughts in the same narrative description. It is more important to check the relationship and attributions of entities.
Casid,
Very well written and concise post – I think you hit the nail right on the head. The adherence of the class diagram to the data requirements is the most important aspect of the narrative.
Thank you for your sharing. I like what you said about the syntax, it is an important part we need to pay attention when we try to draw the diagram.
I agree with you. Although the diagram is different from person to person, they all need to deliver same meaning and achieve same objectives as the scenario mentioned previously.
Thank you, Mahugnon. I fully agree with your idea that as long as the associations make sense, it is fine. Every one get different view from their perspectives and it makes the diagrams more accurate and diversity instead of being wrong.
Everyone has a different version of understanding so that everyone probably has a different class diagram derived from the narrative descriptions. It is hard to say all of these can be correct, because during the process of creating a class diagram, the logic and the order can be different from everyone, there may exist some logical error or missing information in the class diagram.
When evaluating class diagrams, we can look what they have in the domain class, does the attribute names and associations have a relationship with this class; do the multiplicity between classes make sense. The wrong multiplicity may lead a misunderstanding which still makes sense, this may disturb the entire system.
Berel,
Great point bringing into perspective the potential of logical errors in the class diagrams. I had not thought about this when making my initial post but I completely agree with you. Kudos!
Excellent explanation, Mengqiao. Logic errors and missing information can be quite common in a class diagram, we have to test them individually while we are evaluating a diagram. Usually, logic errors can be detected by our common sense and professional knowledge. However, for missing information, we have to go back to read the narrative description. Association between classes (multiplicity) should be another critical element to be evaluated, and people won’t be able to understand this diagram if some obvious mistakes happen right here.
Thank you for your sharing. You are right. I also comes out a question that is there a situation that both two different diagrams for the same processes will be correct? or there must have one contains frauds.
Hi Hanqing,
Thank you for your comment and question. I would say, it may contain fraud if the person who is doing both of the two diagrams has something ethics issues or just logic error or the person misunderstand the meaning and misrepresent the diagrams.
Hi Mengqiao, I agree with you opinion. It is not easy for all class diagram to be correct especially when losing information or logical errors. But it is also possible for class diagram to be correct if we all can deliver the same information as the narratives. And it is a good way to evaluate class diagrams based on attributes, relationships, and multiplicity.
Beryl
I agree with you. You made a great point about the possibility of potential errors. It is also an important part. I did not think of that when writing my comment either but I agree with you. And despite the differences the diagrams should all deliver the same meaning.
Thank you for your sharing Menqiao. It is true that even everyone has a different version of understanding, but it is still hard to said all of these can be correct. We need to exclude the logical error or missing information.
I agree with you. as the saying goes, there are a thousand Hamlets in a thousand people’s eyes.
Some objective factors provided in the narrative can be used to evaluate the diagram. Diagrams can be different based on different understanding of narrative. But objective factors such as classes, relationships and attributes should be identified in the same manner. The order of classes and diagram layout can be different based on personal preferences, the objective factors have to match up the information provided. And they should be identified in correct sense.
Hana,
You bring another great point in the “correctness” of a diagram. I agree that diagrams will be different as a result of the different understanding of the narrative. However, if the narrative is misinterpreted – does this make the diagram wrong, even if it meets all the necessary data requirements?
I agree with you, Xiaozhou. Classes, users, and association should be three most essential elements to be tested while we are evaluating a class diagram. Both classes and users should come from the narrative directly without any assumption. Also, association (relationship) should be identical for everybody’s diagram, because we probably apply our common sense and a little bit professional knowledge to judge it. Eventually, for attributes, since every class could have multiple attributes, our diagram could be slightly different.
Hi Hana, I agree with your idea which is simple but clear. Although there might be difference among different people regarding the diagram, the information we need to deliver is same. I do agree with you that the information in our diagram should match the information in the narrative.
Hi Hana
I agree with you. even thought the diagram layout can be different with each person, the objective factors have to match the narrative otherwise The ERD will be describing something completely different. Another narrative
Thank you Xiaozhou, I agree with you on the idea that there are objective factors exist but objective factor also used.
I think you bring up a great point about how there is some objectivity is database design. Though there isn’t a “right” way to do something all the time, I think it’s important to remember that there are some relationships in design that are critical and can cause problems later in the life cycle if misunderstandings in the present are not cleared.
Determining whether class diagrams are correct or not goes back to analyzing the business requirements. The need to capture data arises when business and system analysts gather information on what the business needs a system to do. Once the functionality of the system is decided, data requirements come into play. Since there is a subjective element to developing class diagrams, one can not assume all of them to be correct as there is possibility of misinterpreting what the business requirements ask for. When it comes to evaluating the diagrams, one must look at each domain class and determine if it is something that can tracked or must be tracked according to the business requirements. Each domain class should have a unique identifier along with attributes which can be used to create specific instances or objects of the class. Associations must also be taken into consideration in the context of the business requirements. Class diagrams should represent the associations in accordance of relationships the requirements are describing. Data requirements ultimately come from what the business wants the system to do so doing a check of the class diagram against the business requirements is a way to see what is accurate vs what is not accurate.
Hi Sarush,
Great idea referencing the class diagram back to the business requirements. It is easy to forget the business requirements of any IT system diagram while trying to meet the necessary data and technical requirements. Great connection!
Good Job. On diagram evaluation, one must examine each domain class and determine if it can align with the business requirements. It is also necessary that each domain should have unique identifier and attributes that can be used to create specific instances. We should also understand that data requirements come from what the business wants the system to do.
You bring a great point that the understanding should go back to the business requirements. However as you mention, the business requirements have the potential to be misunderstood. This reiterates the importance of not only have clearly defined business requirements but also working with all stakeholders during the collection of these to help ensure a holistic understanding.
Thank you for your sharing Sarush, you mentioned a good idea about the business requirement and data requirement, which should be considered on the evaluations toward the diagram designs.
Great point. The accuracy of all relationships will help to ensure that high cohesion is achieved.
Also, it is important for us to understand that class diagrams are fundamental to the object modeling process. Class diagrams are the blueprints of a system or subsystem. It can be used to model objects that make up the system. We can use it to display the relationship between the objects, and to describe what each object does or the services it can provide. The class diagram helps us to define relationships between classes & classifiers, illustrate the structure of a model by using attributes, operations, and signals, and to show entities as business object models.
I agree with you, because class diagram is a blueprint of a system. It describes the relationship of each entity. Tat makes people understand the logic of the system, and how the system works.
When evaluating class diagrams, we look for the following objectives:
1. Less coupling. Coupling is a quantitative measure of how closely related classes are linked. Two classes are better to be loosely coupled, which means two classes without lots of tightly coupled associations and messages.
2. Cohesion is a quantitative measure of the focus or unity of purpose within a single class. Classes are better to be highly cohesive, which means all of responsibilities of the class are consistent and make sense.
3. Indirection is an intermediate class is placed between two classes to decouple them but still link them. The better class diagram should be the one where indirection reduces coupling or provides greater security.
I agree with you. You list three requirements for how to create a class diagram. It is important to determine the relationship between entities. That presents how the system works.
The process described can be anything: a manufacturing process, an administrative or service process, a project plan. This is a generic tool that can be adapted for a wide variety of purposes.
Hi Jing,
Very short and concise post, I think your comment provides a different perspective on the technical nature of class diagram evaluation and modeling. Thanks for sharing!
Great points. As you rightfully said it is important not to place too many responsibilities on an object. A class can be subdivided to show the different operations that exist at each subclass and a class can have associative classes and they can be shown by the relationships. Separation can be used to evaluate the designs to check whether objects can do “what they do best” and reduce objects associating with all other objects. If this is the case there might be confusion for other people interpreting the diagram like the programmer.
You made a different but very good point. you have a different perspective which is a good thing. Your methods of evaluating class diagrams: Less Coupling, Cohesion, and Indirection are good and can be applied t any process, like Hana suggested Above. Thanks for sharing this great comment
Thank you for your sharing, thank you for your sharing for those there concept, I think they are good standard to evaluation the diagram logics.
Different people may have different thoughts under the same scenario. However, it is difficult to determine which is right and which is wrong. To evaluate the correction of these diagrams, it is important to evaluate the relationship between different subsystems, because class diagram describes the structure of systems. It is important to show the logic of the system by creating relationship between subsystems. It helps reader to understand how the system works. In addition, it is important to understand the attributions of each subsystems. People should list the attribution of the subsystems on the diagram. That helps readers to understand the relationship and the subsystems.
Well said, Xinteng.
I agree with you that different people will have different thoughts based on the same scenario. You mentioned the important factors to build the class diagram including the proper relationships, correct logic, and attributions.
You bring up an important point of making sure we consider the different subsystems as well. This will help ensure all of the data requirements as considered from not sure a high level.
I totally agree with you, Xinteng! You have made some great points. The thought process behind comprehending the narrative descriptions is different for everyone. However, ensuring relationship between different subset in the diagram to define the structure will make the evaluation process easier.
Hi Xinteng,
Good point. Your explanation of the structure of systems is clear and come with good suggestions.
I agree with you. In order to evaluate the revisions of these figures, it is important to evaluate the relationship between different subsystems because the class diagram describes the structure of the system.
Both of data flow diagram and use case diagram are used to view the system from different angles. A data flow diagram is a graphic representation of the flow of information or data in a system or portion of system. It consists of data flows, processes, sources, destinations, and stores.
A DFD only shows the sources and destinations of data coming and going from the system and the transformation of data when it passes through some system process. A use case is used to capture the functional requirements of the system. A use case is a high- level piece of functionality that the system will provide to different actors interacting with the system.
It is possible that each class diagram can be correct. This is because although class diagrams may vary be design as a result of the diversity of thoughts and perspectives – it is possible that all class diagrams will capture the necessary data requirements. These requirements include:
1. Identify and Model Classes – An analysis of the interrelationships, information needs, and actors and prototypes is conducted on the basis of general domain knowledge, discussions with experts, and documents.
2. Identify and Model Associations – A model of the interconnections between the obtained classes and business rules in class diagrams as associations with meaningful names and multiplicities.
3. Define Attributes – The required information about a class has to be identified and modeled in the form of attributes
4. List Required Queries and Inputs – The individual queries and inputs of the IT system have to be identified.
5. Formulate queries and input – Consolidate and finalize class diagram
Review the flowchart with others involved in the process (workers, supervisors, suppliers, customers) to see if they agree that the process is drawn accurately.
I agree. You bring up an important consideration that we must also make sure meaningful names related to the attributes. This helps ensure the class diagram is being properly understood because as you mentioned everyone has a diverse perspectives and may interpret a generic attribute name, for instance, incorrectly.
An initial diagram is a general overview of what the stakeholders think the business process looks like. This is the general diagram that you will be “fleshing out” throughout the diagramming process. Before crafting this diagram, sit down with stakeholders to come up with initial, high-level steps in the business process.
You mentioned a very important point of stakeholder involvement in the requirements gathering phase of the system development. The information that the stakeholder provides give direction to the model of the class diagram. This narration should be used to identify the objects which act or behave a certain way and group them into classes, then the operation is derived from what the stakeholder gives you as the processes of the different objects. All this information you get from the stakeholder can be used to evaluate whether all the classes, associations and behaviors have been captured and whether they are a true representation of what the user requires. This ensures an efficient and effective system and ensures that the nothing is missed and all the different people involved in the system development have the same understanding and expectations from the system.
Yes, ZHIXIN, I agree with you talk with stakeholders to come up with initial, high-level steps which is useful way.
When we are evaluating a class diagram, there are usually some basic elements that we have to check. Initially, domain classes (things) are important components in a class diagram, and each of them has to work with a user to be effective. Second, users (people) are another important part of a class diagram, and only people who are in charge of a particular process should appear in this diagram. Finally, association (places) is a critical factor to connect two different classes, and the relationship between them should be identified clearly, such as one to one, one to many, and many to many. Testing these factors should be the priority while we are evaluating any class diagram.
I agree with you. Domain classes (things) are important components in the class diagram, they must work together with the user to be effective
The whole idea behind having class diagrams is to have a model that captures the system purpose and to produce a quality system that meet the customer requirements and provides value for the business
Factors to be considered when evaluation the models are:
• The objects should be grouped into classes that share the same features or characteristics, relationships and have the same operations and or behavior.
• Each data store matches a corresponding data class.
• The data flows from and into the data stores must match the data classes and corresponding decisions where need be.
• A study of the decisions to determine the corresponding attributes for the class that links to that decision.
Thank you for sharing your view! I totally agree with your factors that should be consider when evaluation the models.
I agree with your point. we should not forget that the whole purpose of having a diagram is to captures the system purpose and meet the customer requirements. You made a short but good comment, especially your point about the object, data store, data flow, and study of the decisions. Thanks for sharing
Different class diagrams same narrative description is possible, meaning they can all be correct. Though the classes diagram may be different, the must be some similarities or they must meet the same goal. Evaluation can be done ensuring the classes, relationship, association, attributes, multiplicity, etc. are all clearly defined to meet the data requirement of the narrative. The goal of evaluation is to ensure
Less coupling-class linkage;
Cohesion – unity between classes
Reduced Indirection – creating an intermediate class to decouple the classes yet retaining linkage
Everyone has a different understanding of the same thing, it is also same for drawing diagrams. Because human has different views, orders, and thoughts to the processes, so the results been presented are different.
Thus, it is possible that each class diagram can be correct.
Thus, we should make sure the information we need before drawing the diagrams.
We need to know about the model type we need to use, the model Associations, the relationships between each entities, the attributes, and queries.
I agree with your idea. The class diagram can be correct if all these diagram deliver the same information even in different ways. And how to evaluate it should be based on if the information delivered by diagram match up the information gives in the narrative.
Basically, the diagrams are not the most important. As there can be different diagrams but the information contained in the diagrams and the narrative are crucial.
“Saying or interpreting the same things(narrative) in different ways.”
I like your point. “Everyone has a different understanding of the same thing, it is also same for drawing diagrams. Because human has different views, orders, and thoughts to the processes, so the results been presented are different.”
When evaluating class diagrams, we should ensure that the diagram captures the necessary data requirements – like the type of relationship – an association between the instances of one or more entities types that is of interest to the organization. We should identify the number of entity types that participate in that relationship – the common relationship in entity relationship are unary, binary, ternary. Attributes – they are the characteristics of an entity that is of interest to the organization. (attributes provide required information about a class). Associations – the interconnection between obtained classes and business rules in a class diagram. Dependency – a semantic connection between dependent and independent model elements; aggregation – this can occur when a class is a collection or a container of other classes. It is also necessary to identify the individual queries & inputs required in the IT system.
I think something important you mention is that making sure the main data requirements are the same. If secondary activities or attributes are different in a class diagram, it may not be as detrimental if there are some discrepancies.
The class diagram describes the overall system structure. The system structures are built from classes and relationships, The classes include information, products, documents, or organizations.
Designing and evaluating the class diagram narratives ties strongly with the business analysis (BA) and system analysis (SA) of the project. However, the key components of the chart will be identical and they will be capturing the major entities, attributes, and relationships.
Because class diagrams are used for a variety of purposes – from understanding requirements to describing detailed design – Designers will need to apply a different style in each circumstance.
Hi Mahroo, I like your point which is clear and straightforward. And I agree with that the key components of the chart will be identical, so it is a good way for us to evaluate the class diagrams.
We probably has a different class diagram derived from the same narrative descriptions base on different people’s understand is different. It can’t be all of the transaction are correct because there would be something mistake of logic or others. but we can pay more attention on the core activities.
Very concise and well explained, Linlan. People have different understanding on the narrative descriptions. However, if the core activities are uniform in all the diagrams, then it can be said that the diagrams are error free.
The core activities are very important. There needs to be a message that is conveyed to everyone involved. If you are getting your point across you are doing something right.
Well said. Even if we draw a class diagram from the same narrative descriptions, those class diagrams could not be all correct.
Good explained. Because everyone thinks different, and none can do the all correct.
I think it is possible to have all class diagram correct if all these diagrams deliver the same information as mentioned in the narratives. We all have different understandings, styles, and preferences when create the diagram, but we have the same objective which is to clearly transfer necessary information from the narrative to diagram. With this objective, we were actually doing the same things but in different ways. To evaluate class diagrams, we can compare the attributions such as names, logic, and relationships. Because there might be difference in styles, forms and preferences but the information we need to transfer is same and clear in the narrative. In fact, a diagram is good if the diagram delivers accurate information from the narrative.
I agree that it is possible to have multiple correct answers to a class diagram if all of the information mentioned in a narrative is considered and used correctly. Furthermore, evaluating attributes, logic, and relationships is a good idea for consistency.
Owning the same information is definitely important for all the diagrams to be correct. I think that it can look a bit different as long as the same points are being communicated.
Based on the different understanding, each of us might create different diagrams. I think the diagrams do not have to look same but the structures and requirements need to be in a similar form. To evaluate the class diagrams, we can evaluate the following elements:
–relationship sets
–data consistency
–primary keys and foreign keys setting
I agree with you, Dongjie! The structure and requirements is important to address the narrative descriptions. Diagrams may differ from one another, but it is significant that elements that are used to evaluate the diagrams should be the same.
I agree with you Dongjie, people would have different understanding and idea base on their knowledge,
These elements are definitely important for evaluation, especially data consistency. Being inconsistent will cause confusion for all parties involved. The structures should be similarly constructed.
Nice point, even if we draw a class diagram from the same narrative descriptions, we may not have different interpretation of it.
Nice point, even if we draw a class diagram from the same narrative descriptions, we may have different interpretation of it.
I agree with you Dongjie. The class diagram can be similar, but cannot be the same. Cause everyone has their different thoughts in their brain.
Hi Dongjie,
Excellent point. The key elements must be in place to assist in evaluating the diagrams. Therefore, it is not needed for the evaluation of the class diagrams to occur.
A class diagram is a graphic representation of the structure of a system by showing the objective classes, the internal structure, and the relationship among the classes.
Although all participants read the same narrative description, every participant tends to generate different understandings of the business units, services, roles, responsibilities, and functionalities.
In order to capture all requirements when creating a class diagram, it is important to consider following criteria:
1. Identify types of operation. Operation can be categorized into three types depending on the types of service: constructor, query, and update.
2. Define associations. An association is a relationship among instances of object classes.
3. Identify associative class. An associative class is an association that has attributes or operations of its own or that participates in relationships with other classes.
4. Identify generalization. Generalization is a process of abstracting common features among multiple classes, as well as the relationships among the classes.
Nice point. In my opinion, we could also evaluating class diagrams by look at the cohesion and coupling in the diagrams. It is best to have classes that are loosely coupled and highly cohesion.
Good post.Even though all participants read the same narrative description, each participant tends to have a different understanding of business units, services, roles, responsibilities, and functions.
I believe it is not entirely necessary for everyone’s diagram to look the same despite the same narrative description. However, the key thing to remember is the relationship that describes the structure of the diagram should not be different. A clearly defined relationship between different elements in the diagram is required to understand the purpose and cohesion.
Hi Binju,
I agree. I am certain that everyone’s diagram look different. However the relationships between elements should be consistence. ON the other hand if the relationship differed the structure of the diagram would be false and never cohesive.
Yes, everyone’s diagram will differ because of the difference in interpretation of the reading, as well as some provided details could have been overlooked. However, there should be certain key factors that will not differ too much. The data model reflects the business rule which drives the nature of the organization and the rule outlines the data’s features. I think that as long as everyone understands the rule clearly the data characteristics on the diagrams should have some similarity.
Data modeling and business rules definitely should be correlated. Without these things working together the model will be useless. People need to be able to understand what is being conveyed and it must be clear.
It is true that different people can have various views toward same things, which raised different class diagram derived from the same narrative descriptions. I do believe there are no correct or wrong from the perspective, however, at the same time the logical error and factors missing must be brought into considerations, which must be considered subjectively. In business world, the business objective, benefit cost balance, return of revenue should also be considered during the evaluations. We should keep our designs as flexible as possible, but from the other sides we need to keep it under certain standard to make it concise, logical and efficient.
Flexibility is agree, I absolutely agree with that. If we are not able to edit our projects we may not be able to have an effective outcome. When things need to change for betterment of everyone, it should happen.
Diagrams will almost never be perfectly alike. People have different ways of viewing and interpreting, and it is our own unique experiences and quirks that affect these things. It is possible for all of these diagrams, but they all cannot be too different. There should be a set amount of requirements in order for the diagram to be effective. I liken this to a baseball swing. All have different flavors to them, but when look at the swing at impact with the baseball you will notice that all swings are very similar. This needs to hold true for the diagram.
I totally agree with you, everyone sees the things from different ways, and they can’t think out the same diagrams in their mind.
As the saying goes, there are a thousand Hamlets in a thousand people’s eyes. Even if we draw a class diagram from the same narrative descriptions, those class diagrams could not be all correct. When we evaluating class diagrams, we can look for the cohesion and coupling. For the coupling, we can see how closely related classes are linked from a quantitative measure; if two classes are tightly coupled, there are lots of associations and messages with another class. It is best to have classes that are loosely coupled. For the cohesion, we can focus or unity of the purpose within a single class from a quantitative measure. One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class; one class has low cohesiveness if its responsibilities are broad or makeshift. It is best to have classes that are highly cohesive.
HI Xiaomin,
I like that statement. I never heard that before…
I can say for sure that I misused some of the narratives when I completed my diagram. This is not to say that my diagram is incorrect it just means my interpretation of the information differed. As stated by Dongjie above the diagram should have a few evaluate elements (i.e relationship sets, data consistency, primary keys and foreign keys setting) which would support cohesion
I agree with you. For coupling, we can see how close the correlation between related classes and quantitative measures is; if two classes are tightly coupled, then there will be many associations and messages with another class. It is best to have loosely coupled classes.
There can be many different ways of thinking in this situation as well as different beliefs in what is right and wrong. It is important to evaluate the relationship between different subsystems to evaluate if the diagram is correct because class diagram describes the structure of systems. Showing the logic of the system by creating relationship between subsystems is a top priority because the goal is to help the reader understand how the system works. I believe it is done right if you are successful in delivering the system as clearly and concisely as possible.
Do to the variations in use cases and the opinions on how to classify entity’s, attributes and relationships it should be expected to have variations in diagrams. I think in order to realize if the diagram is fundamentally right or wrong comes and the question of does it objectively meet its goal of showing how a process can be completed with the rules of a diagram.
When evaluating class diagrams, we reduced coupling. Coupling is a quantitative measure of the close relationship between related classes. The two classes are preferably loosely coupled, which means that the two classes do not have a large number of tightly coupled associations and messages. Cohesion is a quantitative measure of the focus or unity of a single category of goals. The class is more suitable for having a high degree of cohesion, which means that all responsibilities of the class are consistent and meaningful. Indirectly, you place an intermediate class between two classes to decouple them, but still link them. Better class diagrams should be class diagrams that indirectly reduce coupling or provide greater security.