Back to Coursework 2 page

Differences Between OO and SSD

The following characteristics of Object Orientation had a positive impact on our case study Sales Order system.

• Re usability - A powerful feature of the OO is that the classes, Use Cases and objects can be re used in the same or in a different application. The classes that we have used in this system could be used in another similar system. This will minimise the amount of time and labour in defining new entities.

• Inheritance - Sales person, Customer and supplier inherit the attributes from the class Person. Because of this characteristic it is not necessary to define attributes for each of the classes i.e. Sales Person, Customer and supplier.

• Aggregation - The class Date is used in component classes, Order class, Item Class and Commission class. As examples, in Order Class the lead-time of the order can be identified. In Commission class it will assist in calculating the correct commission for the Sales Persons. In Item class it will assist to find out when an item is available for despatch.

• In Entity Relationship Diagrams you can not show Many to many (M:N) relationships. If there are M:N relations, those have to be decomposed. But in OO you can show 1:1, 1:M and as well as M:N relationships. Because of this feature it eliminates the hazel of creation of Joining tables

• When implementing the system it would be convenient for the developers since OO Design generates classes. This facility will assist the developers to generate code in a much more organised way.

• It is easier to understand the functionality of OO than SSD. In a DFD or ERD the users have to visualise how the system is going to function. But in OO the functionality is apparent since the performance of each element is clearly defined. As an example in a class the objects are clearly connected to actions that they perform since a class contain both data and procedures.

• It is easy to add functionality. Since the Use Cases are uniquely defined for each of the requirement, the developer will know exactly where and what to change without affecting the system. This because you can always extend a class via inheritance, without having to change the existing code.

• From the point of view of the users, the Use Cases will assist to understand the functionality it provided by the system than the context diagram. Also Uses Cases will save time in implementation since they can be extended or re-usable.