Location: [CPSC 333] [Ongoing Examples] Cartography System
This page was most recently modified on March 7, 1997
This system will be used to maintain information about a set of maps of (parts of) the world. Each map has a unique map number. The part of the world that is displayed by a map is given by the easternmost and westernmost longitudes, and the northernmost and southernmost latitudes, that are displayed.
The system also maintains a small amount of information about countries and cities of the world. In particular, the (unique) name, total population, and total area of each country is maintained, as is the name of its capital city. The name, latitude, and longitude of each city are maintained by the system. No two cities in the same country have the same name.
Finally, the system can be used to determine which maps show any given city, and to determine where a city is shown on a given map, if that city is shown on it. One can also determine which maps display (at least a part of) any given country.
This system will be considered in several assignments.
For this example, a few things that wouldn't necessarily be considered as part of a requirements specification will be shown, because they form part of the solutions for Assignment #1.
This certainly isn't the only acceptable ERD that could be given as a solution for Assignment #1. Some groups may have noticed (or made the reasonable assumption that) a city's longitude and latitude could form a key for it. If they realized this, and used these as a key, then ``City'' would be shown as an entity instead of a weak entity, ``city name'' would become a ``non-key attribute,'' and it would be necessary to introduce one more relationship, ``is contained in,'' between City and Country (of type 1:Mc - each city would presumably be contained in exactly one country, while each country could have zero or more cities contained in it).
I've chosen not to use the city's latitude and longitude as its key, because it seems unlikely that a user of the system would have this information available, when that user wants to obtain more information about the city. It seems more likely that the user would know the name of the city and the country in which it lies, instead.
If a different (reasonable) ERD was given, then of course a different data dictionary, etc., would be correct. Later parts of the assignment submissions will be checked for consistency with the beginning of the submission (namely, the ERD), rather than agreement with what appears below this.
One solution for the rest of the assignment - one that agrees with the ERD shown above - will be given here.
The ``map number'' would be the only attribute in the primary key for this entity.
The ``country name'' would be the only attribute in the primary key for this entity.
A primary key for this weak entity would be obtained by including the attribute ``city name'' along with the primary key (``country name'') for ``Country.''
The relationship ``shows'' has type Mc:Mc - each map can show zero or more cities on it, and each city can be shown on zero or more maps.
The relationship ``displays'' has type Mc:Mc - each map can display (a part of) zero or more countries, and (part of) each country can be shown on zero or more maps.
The relationship ``is capital of'' has type 1:1c - each city is the capital of at most one country, and each country has exactly one city as its capital.
Furthermore, the capital city of any country is one of the cities that is contained in it. This fact will be used to produce a data dictionary definition for the relationship ``is capital of'' that might be slightly different than expected.
A complete (and detailed) list of the operations corresponding to one entity and one relationship were requested, along with a less detailed list of the names associated with the rest. In the solutions given below, the operations associated with the entity ``Map'' and the relationship ``shows'' will be described reasonably completely.
Operations that might be associated with the entity ``Map'' include the following.
Add Map
Inputs: All of the attributes of ``Map''
Effects: If the inputs are syntactically correct and the given ``map number'' isn't already in use, then a new map is created and added to the system's data base
Correct Map Information
Inputs: All of the attributes of ``Map''
Effects: If the inputs are syntactically correct and the given ``map number'' is in use, then the corresponding instance of map is modified, by using the rest of the inputs to reset the values for the instance's non-key attributes
This could be done differently: For example, you could have a separate operation used to change the value of each one of the non-key attributes, instead - with names like ``Correct easternmost longitude,'' ``Correct westernmost longitude,'' etc., and each taking two inputs - a map number, and a new value for the non-key attribute mentioned in the operation's name.
Delete Map
Inputs: map number
Effects: If the input is syntactically correct, corresponds to a map that's in the system, and there are no (parts of countries) listed as displayed on it, or cities listed as shown on it, then the corresponding map is deleted.
This could also be done differently: For example, a less cautious approach would be to have the the system go ahead and delete all the corresponding instances of the relationships ``shows'' and ``displays'' when a map is deleted, instead (as above) of refusing to perform the deletion when any of these instances exist. One way or the other, though, you should ensure that the data base isn't ``corrupted'' (by having instances of ``shows'' or ``displays'' that refer to deleted maps, left in the system).
Display Map Information
Inputs: map number
Effects: If the input is syntactically correct, and corresponds to a map that's in the system, then the values of all the non-key attributes of this map are displayed to the user.
Operations associated with the entity ``Country'' would probably include the following.
Creation of a ``Country'' would be a bit trickier than creation of a ``Map:'' you'd likely need to create at least one ``City'' that's located in the country (namely, its capital city), at the same time as you ``create'' the country (because of the ``type'' of the relationship, ``is capital of,'' that's listed above).
Deletion of a ``Country'' would be a bit tricker than deletion of a map, as well: While you might refuse to delete a country if any cities except for its capital presently exist, you'd likely need to delete the capital city at the same time as the country.
Operations associated with the entity ``City'' would probably include the following.
Again, you'd probably need to do something like refuse to delete a ``capital city'' unless this is done at the same time as its country is deleted, in order to avoid corruption of the data base.
Operations that might be associated with the relationship ``shows'' might include the following.
Enter Display of City
Inputs: map number, country name, city name
Effects: If the inputs are all syntactically correct, correspond to an existing map and city, and if it's possible for the city to be displayed on the map (because the country containing the city is shown on it, and the city's latitude falls between the map's northernmost and southernmost latitude, and the city's longitude falls between the map's easternmost and westernmost longitude), then the fact that the city is shown on the map should be entered into the system's data.
One might reasonably argue that it shouldn't be a responsibility of the ``data management subsystem'' to compare the city's latitude and longitude to the map's, etc.; if you feel that this is the case, then you'd leave part of the ``error checking'' (suggested above) out of the description of the operation.
Delete Display of City
Inputs: map number, country name, city name
Effects: If the inputs are syntactically and correspond to an existing city that's shown on an existing map, then the information that the city appears on the map is deleted from the system.
List Cities Shown
Inputs: map number
Effects: If the input is syntactically correct and corresponds to an existing map, then a list of the keys (country name and city name) for each of the cities shown on that map is produced.
List Maps Showing City
Inputs: country name, city name
Effects: If the inputs are syntactically correct and correspond to an existing city, then a list of the map numbers of maps showing that city is returned.
One more operation might feasibly be included,
Is City Shown on Map?
Inputs: country name, city name, map number
Effects: If the inputs are syntactically correct and correspond to an existing city and map, then a Yes/No answer to the above question is returned.
Operations corresponding to the relationship ``displays'' might include the following.
Finally, the operations corresponding to the relationship ``is capital of'' might include the following.
Because of the ``type'' for the relationship that was given above, you can't add and delete capitals as freely as you can add and delete other things; instead, you can really only replace the city listed as capital for a country, by another city in the same country. See the discussion of addition and deletion of countries, given above, if you wish to think about this some more.
This uses ``auxiliary definitions'' to define some attributes with common data types (which was discussed via email and the newsgroup, during work on the first assignment). It also ``bends the rules,'' by treating latitudes and longitudes as single attributes, even though they neither have ``elementary'' data types or represent ``enumerated sets.''
Name: area
Kind: At
Type: integer
Description: Non-key attribute of Country (Note: It might be appropriate to list a unit of measure, such as ``square miles'' here, but no one asked about this, so one won't be specified.)
Name: City
Kind: WE
Type: @country name + @city name + citys latitude + citys longitude
Description: Represents a city that might be shown on one or more maps
Name: city name
Kind: At
Type: string
Description: Key attribute of City
Name: citys latitude
Kind: At
Type: latitude
Description: Non-key attribute of City
Name: citys longitude
Kind: At
Type: longitude
Description: Non-key attribute of City
Name: Country
Kind: E
Type: @country name + population + area
Description: Represents a country that might be displayed on one or more maps
Name: country name
Kind: At
Type: string
Description: Key attribute of Country
Name: displays
Kind: R - Mc:Mc
Type: @map number + @country name
Description: Relationship between Map and Country; each map can display (part of) zero or more countries, and (part of) each country can be displayed on zero or more maps
Name: easternmost longitude
Kind: At
Type: longitude
Description: Non-key attribute of Map
Name: first letter used
Kind: At
Type: string
Description: Non-key attribute of Map; represents the label of the easternmost vertical subdivision on the map
Name: first number used
Kind: At
Type: integer
Description: Non-key attribute of Map; represents the label of the northernmost horizontal subdivision on the map
Name: is capital of
Kind: R - 1:1c
Type: @country name + city name
Description: Relationship between City and Country; each city can be the capital of at most one country (and, this must be the country that the city is contained in), and each country has exactly one city as its capital
Name: latitude
Kind: H
Type: latitude distance + latitude direction
Direction: Used to define citys latitude, northernmost latitude, and southernmost latitude
Name: latitude direction
Kind: H
Type: [ `N' | `S' ]
Description: Used to define latitude
Name: latitude distance
Kind: H
Type: real
Description: Unit of measure is ``degrees;'' should be between 0 and 90, and should represent numbers to an accuracy of at least one digit after the decimal point. Used to define latitude
Name: longitude
Kind: H
Type: longitude distance + longitude direction
Description: Used to define citys longitude, easternmost longitude, and westernmost longitude
Name: longitude direction
Kind: H
Type: [ `E' | `W' ]
Description: Used to define longitude
Name: longitude distance
Kind: H
Type: real
Description: Unit of measure is ``degrees;'' should be between 0 and 180, and should represent numbers to an accuracy of at least one digit after the decimal point. Used to define longitude
Name: Map
Kind: E
Type: @map number + easternmost longitude + westernmost longitude + northernmost latitude + southernmost latitude + number of vertical subdivisions + first letter used + number of horizontal subdivisions + first number used
Description: Represents a map of part of the world
Name: map number
Kind: At
Type: integer
Description: Key attribute of Map
Name: northernmost latitude
Kind: At
Type: latitude
Description: Non-key attribute of Map
Name: number of horizontal subdivisions
Kind: At
Type: integer
Description: Non-key attribute of Map; should be greater than zero
Name: number of vertical subdivisions
Kind: At
Type: integer
Description: Non-key attribute of Map; should be greater than zero
Name: population
Kind: At
Type: integer
Description: Non-key attribute of Country
Name: shows
Kind: R - Mc:Mc
Type: @map number + @country name + @city name
Description: Relationship between Map and City; each map can show zero or more cities, and each city can be shown on zero or more maps
Name: southernmost latitude
Kind: At
Type: latitude
Description: Non-key attribute of Map
Name:westernmost longitude
Kind: At
Type: longitude
Description: Non-key attribute of Map
[Problem Statement] [References in Assignments] [Solutions for Assignment #1]
One possible class diagram for this system is as follows.
Several variations are possible.
In the above diagram, a ``whole-part structure'' including ``Country'' and ``City'' is used to model the requirement that each city be part of exactly one country (and each country can have zero or more cities in it), while an instance connection between the classes is used to model the requirement that each country has exactly one city as its capital, and each city is the capital of either zero or one country. An alternative diagram might use instance connections to model both requirements (replacing the whole-part structure by an instance connection); in this case, you'd clearly need to label both instance connections so that they could be distinguished (and, it's perfectly acceptable to label the one shown in the above diagram, with a name like, ``has capital,'' if you wanted to do that too).
You might choose to replace the instance connections between ``Map'' and ``Country'' and between ``Map'' and ``City'' with whole-part structures as well, but I think that the argument for using these here is less clear than it is for using a structure between ``Country'' and ``City.''
Finally, a class ``Clerk'' is included here because of an assumption made about the system's interface with the user - namely, that it will be useful to have a class responsible for prompting the user for commands, and then sending messages to other classes to have the commands executed. If there's no need for a class with this responsibility, then there's no reason to include a ``Clerk'' class here (since it will have no attributes in the version of the system that's being considered now).
``Clerk'' has no attributes. One could use the same set of attributes for the classes ``Map,'' ``Country,'' and ``City'' as were used for the corresponding entities.
Since ``normalization rules'' are less important for object-oriented analysis than for information modeling, one might also choose sets of attributes in the above list that are going to be used altogether, and replace each set with a single attribute (having the attributes in the corresponding set as ``components.''). In particular, one might group together the current attributes ``easternmost longitude,'' ``westernmost longitude,'' ``northernmost latitude,'' and ``southernmost latitude'' of ``Map'' and replace them with a single attribute, ``area displayed,'' for the class ``Map.'' Similarly, one might group together the attributes ``number of vertical subdivisions,'' ``first letter used,'' ``number of horizontal subdivisions,'' and ``first number'' used into an attribute, ``grid information,'' that happens to have four components (it seems likely that, for any given service, you'll either need all four of these values, or you won't need any of them at all, so that grouping them together makes sense). Finally, one could pair up the attributes ``city's latitude'' and ``city's longitude'' of ``City,'' to produce a single attribute called ``location.''
It isn't necessary or desirable to store either more, or less, information for this version of the system than it is for the one specified using ``function-oriented'' (that is, ``structured'') techniques, so these are the only changes in attributes that come to mind.
Here is a revised list of attributes that incorporates these changes.
Some assumptions must be made before this part of the question can be answered. There will be lots of other assumptions that one might plausibly make, as well - so there will be lots of different ``correct answers'' for this part of the question.
An assumption about the interface has been already been discussed, and was used to justify the inclusion of a class called ``Clerk.'' Due to this assumption, ``Clerk'' will receive the request to ``List Maps for a Given City.''
Another assumption deals with which class - ``Map'' or ``City'' - keeps track of the instance connection between them. This is relevant, since the information that must be returned is essentially a report of a particular subset of the connections that this ``instance connection'' represents. For this answer, I'll assume that ``Map'' keeps track of these. I'll also assume that ``Map'' is the class that will provide the ``service'' that the ``Clerk'' invokes, in order to satisfy the user's request. This makes the message threads for this operation a bit longer than they otherwise might be, but it would simplify the message threads needed for a request to display information about a given map.
Finally, we must make some assumptions about how an existing city will be specified, and what errors (or relevant decisions that the user can make) are possible. For this answer, I'll assume that the ``City'' class provides a service that can be used to ``Get an Existing City.'' The class will display a list of the cities known to the system in some way, so that syntax errors, selections of nonexistent cities, etc., aren't possible.
While no ``errors'' are possible, I'll assume that the user can choose to cancel the operation instead of selecting a city.
Under all these assumptions, only two ``threads of execution'' related to this operation seem possible.
The first three steps here are identical to the first three given above. For the fourth step, a ``cancel'' signal is returned as a reply from ``City'' back to ``Map,'' since the user requested cancellation of the operation instead of selecting a city. As above, the ``Map'' class sends a ``finished'' reply to the ``Clerk'' class in the fifth step.
Only two message connections - from ``Clerk'' to ``Map,'' and from ``Map'' to ``City,'' are used above (recall that we don't introduce message connections to show transmissions of replies to requests). A class diagram that shows these is as follows.
Location: [CPSC 333] [Ongoing Examples] [Cartography System]