Unit_4 Domain Modeling

Unit_4 will focus on a key concept that defines requirements: THINGS in the problem domain of system users. We first can also relate THINGS to data entities or domain classes like when we think about USE CASES. THINGS define the sources for the tables used in a relational database management system. Most approaches to system development include identifying and modeling data entities or domain classes as an important task in the analysis activity DEFINE FUNCTIONAL REQUIREMENTS. 
THINGS ->> Domain classes or data entities that end users deal with when they do their work- for example, products, sales, shippers, shipments, and customers,(as they are referred to in the context of a system's problem domain.)
PROBLEM DOMAIN->>A specific area of the user's business that is included within the scope of the new system . The new system involves working with and remembering these THINGS.
More often than not THINGS are related to the people who interact with the system or to the other stakeholders. [ a customer is a person who places an order BUT the system needs to store information about that customer, so a customer is also a thing in the problem domain. HOWEVER the system may need to store information about products, shipments, and warehouses, THESE ARE NOT!! persons. 
The two techniques for identifying the important THINGS in the problem domain that we will address are : the brainstorming technique and the noun technique.

The above cardinality constraint on the Order data entity indicates that there can be ONE OR MANY ORDERS .

 Generalization/Specialization Association

An Attribute whose value uniquely identifies an object is called a KEY ATTRIBUTE

The number of associations that occur among specific things in an entity relationship diagram is called CARDINALITY

In the traditional approach to system development, the system stores information about DATA ENTITIES

AN ASSOCIATION RELATIONSHIP would not be an appropriate way to describe a relationship between an employee and his/her manager,whereas, UNARY RELATIONSHIP BINARY RELATIONSHIP AND GENERALIZATION/SPECIALIZATION RELATIONSHIP would be appropriate. 

A class that represents a many-to-many association between two other classes is called an ASSOCIATION CLASS

If we modeled a "sale" and the "sale items" with a whole-part relationship, it would be best described as A COMPOSITE RELATIONSHIP.

In a generalization/specialization relationship, it would not make sense for a class at the bottom of the hierarchy to be an ABSTRACT class

Inheritance describes a condition between classes where classes share some attributes.