16. Accountability and Affiliation

Affiliation

An organizational model of an enterprise such as a business, government, or university must take into account two things:

1. Types of organizational units
2. Organizational rules Assume a particular business is organized into divisions. Each division is organized into departments, and each department is organized into offices. Thus, the types of organizational units are divisions, departments, and offices. The organizational rules are: 1. Departments are subsidiaries of divisions.
2. Offices are subsidiaries of departments. We might try to capture this information with the following class diagram:

The problem with this model is that both the rules and types of organizations change from time to time and from enterprise to enterprise. It's also not clear how programmers should enforce the constraint attached to the affiliation association.

We can improve the model by modeling organizational types by objects rather than classes:

Now Division, Department, and Office are just sample instances of the OrgType class. If the types of organizational units change, we only need to delete some old OrgType objects and create some new ones.

Of course OrgType objects can also be factories that create properly typed organizations as their products:

// factory method:
Organization* OrgType::makeOrganization()
{
   Organization* product = new Organization();
   product->setType(this);
   return product;
} Facts and Rules

A rule is a general constraint, such as:

Departments are subsidiaries of divisions. A fact is a specific constraint, such as: The sales department is a subsidiary of the marketing division. We can think of the above fact as an instance of the above rule. This suggests that we can think of a rule as the type of a fact. This further suggests that we can explicitly represent rules as classes, and facts as objects:

Thus the facts:

f1: (3 = 4 && 4 = 3)
f2: (4 = 5 && 5 = 4) would be instances of the symmetry rule:

Modeling rules (i.e., fact types) as classes will produce a massive and difficult to maintain hierarchy of classes. A better approach is to model rules as objects:

A Reusable Organization Model

If we take this approach in our organizational model, then we notice that affiliation facts are simply the instances of the affiliation association. Since a fact must store its rule/type, we'll need to represent links between parent and subsidiary organizations as link objects, instances of an association class named Affiliation. An interesting observation is that in this case instances of our rule class-- AffilType-- are link objects that link OrgType instances, making AffilType an association class, too:

Example

Organizations are now modeled by object diagrams rather than class diagrams. For example, at most universities:

Rule: Departments are subsidiaries of colleges.

Fact: The Math and Physics departments are subsidiaries of the College of Science.

 We can represent this organization using the following object diagram:

A C++ Implementation

class Organization
{
private:
   friend class OrgType;
   //default constructor:
   Organization(string nm = "???", OrgType* t = 0)
   :name(nm), type(t)
   {}
   //copy constructor:
   Organization(const Organization& o) {}
   string name;
   OrgType* type;
   Affiliation* parent;
   list<Affiliation*> subsidiaries;
public:
   //getters:
   string getName() const { return name; }
   OrgType* getType() const { return type; }
   //utility functions:
   void setParent(Affiliation* a) { parent = a; }
   void addSubsidiary(Affiliation* a) { subsidiaries.push_back(a); }
   // etc.
};

class OrgType
{
private:
   string name;
   AffiliationType* parent;
   list<AffiliationType*> subsidiaries;
public:
   OrgType(string nm = ""):name(nm) {} //default constructor
   //factory method:
   Organization* makeOrganization(string temp);
   //getters:
   string getName() const {return name;}
   //utility functions:
   void setParent(AffiliationType* a) { parent = a; }
   void addSubsidiary(AffiliationType* a) { subsidiaries.push_back(a); }
};

class Affiliation
{
private:
   friend class AffiliationType;
   AffiliationType* type;
   Organization *parent, *subsidiary;
   // default constructor:
   Affiliation(Organization* p = 0, Organization* s = 0)
   :parent(p), subsidiary(s)
   {
      if (p) p->addSubsidiary(this);
      if (s) s->setParent(this);
   }
   //copy constructor:
   Affiliation(const Affiliation& a) {}
public:
   //getters:
   AffiliationType* getType() {return type;}
   Organization* getParent() {return parent;}
   Organization* getSubsidiary() {return subsidiary;}
};

class AffiliationType
{
private:
   OrgType *parent, *subsidiary;
public:
   AffiliationType(OrgType* p = 0, OrgType* s = 0)
   :parent(p), subsidiary(s)
   {
      if (p) p->addSubsidiary(this);
      if (s) s->addParent(this);
   }
   //factory method:
   Affiliation* makeAffiliation(Organization* p, Organization* s)
   {
      // only creates valid affiliations
   }
   //getters:
   OrgType* getParent() {return parent;}
   OrgType* getSubsidiary() {return subsidiary;}
};
 

 Two Partial Java Implementations
 
 

// simple solution:

public class Organization {
 private OrgType type;
 public OrgType getType() { return type; }
 Organization(OrgType t) { type = t; }
 // etc.
}

public class OrgType {
 private String name;
 public Organization makeOrganization() {
  return new Organization(this);
 }
 // etc.
}

// complex solution:
 

public class OrgType {
 private AffilType parent;
 private Set subsidiaries;
 
 public class Organization {
  private AffilType.Affiliation parent;
  private Set subsidiaries;
  public OrgType getType() { return OrgType.this; }
  // pulic default constructor ok
  // etc.
 }
 public Organization makeOrganization() {
  return new Organization();
 }
 // etc.
 public static void main(String[] args) {
  OrgType league, conference, division, team;
  OrgType.Organization afc = conference.makeOrganization();
  OrgType.Organization nfc = conference.makeOrganization();
  OrgType.Organization nfl = league.makeOrganization();
  // equivalently:
  // OrgType.Organization afc = conference.new Organization();
  AffilType rule1 = new AffilType(league, conference);
  // "type" checking done inside makeAffiliation():
  AffilType.Affiliation fact1 = rule1.makeAffiliation(nfl, afc);
  // etc.
 }
}
 
 
 
 

Accountability

Accountability structures model the relationships between roles. Basically, every role has commissioner roles and responsible roles. For example, a doctor is commissioned by a patient. Nurses are a doctor's responsibles because they are commissioned by doctors.

This is similar to the parent-subsidiary relationship between organizations, but commissioners and responsibles can be any type of role. For example, the CEO of a company is responsible to the company's board of directors, the vice president of the marketing division is responsible to the CEO, the marketing division is responsible to its vice president. Clearly there are many links between commissioners and responsibles and the rules between them can be complicated and they can change frequently.

To cope with this volatility, we can use a version of our reusable affiliation model:







Example

Accountability is called chain of command in military organizations. Here's a bit of the the Star Fleet chain of command:

Rule: Generals command captains.
Rule: Captains command ensigns.
Fact: General Hershey commands Captain Picard.
Fact: General Hershey commands Captain Janeway.
Fact: Captain Janeway commands Ensign Pulver. Our object model:

Problems

1. The 97th Infantry Division of the U.S. Army was active in Europe near the end of World War II. The history and organization of this division is documented on the web at:

http://www.plaisted.org/brothers/97THID.HTM Using the organizational model developed in class, draw an object diagram that shows objects representing the A, B, and C companies of the 303rd and 386th regiments. Your diagram should include all parent organizations that are above these companies in the organizational hierarchy.

2. Translate your model into C++ or Java.

3. The accountability structure of San Jose State University is documented on the web at:

http://www.sjsu.edu/pres/orgchart.pdf Using the accountability model developed in class, draw an object diagram that shows objects representing the head coach of the football team, the chairman of the Anthropology department, the chairman of the Mathematics/Computer Science department, and all of their commissioners.

4. Translate your model into C++ or Java

5. The National Football League (NFL) is divided into the National Football Conference (NFC) and the American Football Conference (AFC). Each conference is divided into Western, Central, and Eastern Divisions. Each division currently consists of five teams. Using the organization model developed in class, draw an object diagram that shows the following teams as well as their conferences, divisions, and league. (You can find out which divisions these teams belong to at Yahoo or at www.nfl.com). Translate your diagram into a C++ program.

Tennessee Titans
San Francisco 49ers
Oakland Raiders
Arizona Cardinals