M206 - TMA07 - Question 2

Project 4 Stage 1 Postings

Posting from Stage 1 Student B writes

It appears that the addition of an instance variable of class Set to class Report may be sufficient to fulfil the responsibility. This responsibility may possibly be described thus:

Keeps track of organisation instances corresponding to named organisations that subscribe to the report.

1 agree with Student B that a Dictionary is the best option here as the Organisations are likely to have unique names so this will provide a unique key. The Dictionary key will hold the Organisation name an the value will hold the reference to the corresponding Organisation object, since this is a small Chamber of Commerce I don't think there will be any problem of two companies having the same trading name. A dictionary does not have a fixed size, so it can grow as circumstances dictate. It does not appear to be necessary to keep track of the order in which Organisations are added, so an ordered collection class is not necessary.

I agree with Student D that Report will require an instance variable called organisation and that the following getter and setter methods will be required,

Any thoughts ????

Class: Organisation		Superclass: (Object)
Responsibility	Type	Smalltalk variables and methods
Maintains the organisation's name.	I	Instance variables: name --- > aString Instance methods: name name: aString
Maintains the organisation's postal address.	I	Instance variables: postalAddress --- > anAddress Instance methods: postalAddress postalAddress: anAddress
Maintains the member's email address.	I	Instance variables: emailAddress --- > aString Instance methods: emailAddress emailAddress: aString
Maintains the reports subscribed to.	I	Instance variables: report - > aSet (a Report, a Report, a Report, a Report) Instance methods. report addReport: aReport removeReport: aReport

 

Class: Report		Superclass: (Object)
Responsibility	Type	Smalltalk variables and methods
Maintains the name of the report's commercial area.	I	Instance variables: area --- > aString Instance methods: area area: aString
Maintains the report's frequency ('M' denotes monthly, 'B' denotes bi-monthly, and 'Q'denotes quarterly).	I	Instance variables: frequency --- > aCharacter Instance methods: frequency frequency: aCharacter
Maintains the Organisations subscribing to a report	I	Instance variables: organisation --- > aDictionary(anOrganisation,  AnOrganisation…) Instance methods: organisation addOrganisation: anOrganisation removeOrganisation: anOrganisation

Stage 2 Postings

Posting 1

Here are my initial thoughts Stage (ii):

Navigation from Organisation to SponsorShip is a one to many relationship so we could use an Array here, however there is a strong possibility of having nil entries in the array where Organisations have not sponsored the full four WorthyCauses. Therefore I would agree with what others have already posted in that a Set is the best way to go This would require a Boolean condition in the setter method to limit the number to four.

Navigation from Sponsorship to WorthyCause would appear to be a one to one relationship in this direction so an instance variable will suffice here.

Navigation from WorthyCause to Sponsorship is a one to many relationship so we could use an Array or Set here. However the last part of the statement reads; 1t is important that navigation from an instance of WorthyCause to the Sponsorship that was committed to first can be carried out quickly. For this reason an Ordered Collection will have to be used since we require to know the order in which Sponsorship was committed. It may also be possible to use a Sorted Collection or some sort of Queue to achieve this. For the Sorted Collection we would have to record the Date and Time of committal to sponsorship as more than one Organisation may commit on the same day and thus the time would also be required to produce the correct sort order. For this reason 1 feel that an Ordered Collection is by far the easiest of the options to implement.

Your thoughts would be appreciated

Posting 2

Re Student E's posting OrderCollection V Sorted Collection

Student E writes:

I agree that the OrderedCollection way is totally dependent on the order in which the committals are added and may not always match the order in which Sponsorships are entered into. If Sponsorships are committed to electronically by the Organisations concerned the order should always reflect the take-up order of sponsorships, however if Organisations commit to Sponsorship by non-electronic means the system is then reliant on the details being input in the correct order.

Student E writes:

If a SortedCollection was used sorted by the date instance variables of the Sponsorship instances, this would ensure correct date order regardless of when the user of the system recorded the sponsorship of the worthy cause. However, if there were equal dates and time was required, 1 don't know if a secondary sort can be included within a sort block.

I agree with the statement above, I have a possible solution though I don't know if it will work in Smalltalk. For this to work it would require a time instance variable in Sponsorship, concatenation or anding of the date and time variables will then produce a unique date/time to sort on, thus ensuring correct order regardless of when the user recorded the sponsorship of the worthy cause. As 1 said I'm not at all sure this will work with Smalltalk though this method works with other languages. If this problem can be resolved then the SortedCollection would be the better option.

Any thoughts???

 Posting 3

Student A Writes:

The idea of using the time of sponsorship as well as the date was to sort on date/time in the SortedCollection. This was to give a unique date/time for when the sponsorship started so that if two or more Organisations committed on the same day the correct sort order would be retained. Anyway I have gone for the OrderedCollection method after trying unsuccessfully to sort date/time on a SortedCollection - probably me or perhaps it can't be done. The only requirement for the OrderedCollection is that the User must make sure that sponsorships are added in the correct order.

Class: Organisation		Superclass: (Object)
Responsibility	Type	Smalltalk variables and methods
Maintains the organisation's name	I	Instance variables: name - > aString Instance methods: name name: aString
Maintains the organisation's postal address.	I	Instance variables: postalAddress - > anAddress Instance methods: postalAddress postalAddress: anAddress
Maintains the member's email address.	I	Instance variables: emailAddress - > aString Instance methods emailAddress emailAddress: aString
Maintains the reports subscribed to.	I	Instance variables: report - > aSet (a Report, a Report, a Report, a Report) Instance methods: reportaddReport:aReport removeReport: aReport
Maintains the sponsorships committed to.	I	Instance variables: sponsorShip --- > aSet (aSponsorShip, aSponsorShip,  aSponsorShip,aSponsorShip) Instance methods: sponsorShip addSponsorShip: aSponsorShip removeSponsorShip: aSponsorShip

 

Class: Sponsorship		Superclass: (Object)
Responsibility	Type	Smalltalk variables and methods
Maintains the start date of sponsorship	I	Instance variables: startDate => aDate Instance methods: startDate startDate:aDate
Maintains the amount of sponsorship.	I	Instance variables: amount --- > aFloat Instance methods: amount amount: aFloat
Maintains the sponsoring organisation	I	Instance variables: sponsorOrganisation --- > anOrganisation Instance methods: sponsorOrganisation sponsorOrganisation:anOrganisation
Maintains the Worthy Cause sponsored.	I	Instance variables: causeSponsored --- > aWorthyCause Instance methods. causeSponsored causeSponsored: aWorthyCause:

 

Class: WorthyCause		Superclass: (Object)
Responsibility	Type	Smalltalk variables and methods
Maintains the WorthyCause name.	I	Instance variables: worthyCauseName --- > aString Instance methods: worthyCauseName worthyCauseName: aString
Maintains the date	I	Instance variables: dateNominated --- > aDate Instance methods: dateNominated dateNominated: aDate
Maintains the sponsors of a WorthyCause.	I	Instance variables: sponsors --- > anOrderedCollection (aSponsorShip, SponsorShip, aSponsorShip...) Instance methods. sponsorShips

Question 1 - Question 3