Introduction to Object-Oriented Design Concepts

1. Introduction to Object-Oriented Design Concepts

2. Object-Oriented Design Overview • Object-Oriented design is basically a set of guidelines/concepts for developing software that is bug free and easily maintained

3. Object-oriented vs. Procedural • Procedural • Programmer is dependent on language-defined data types (primitives) • C offers the struct concept to create compound data types but no way to create operators that work on those user defined types • For function calls data must be passed in via argument lists or globally scoped variables

4. Object-oriented vs. Procedural • Object-oriented • Programmer can create their own data types • In some languages (e.g. C++) the programmer can define operators to work on the defined data types • There are no function calls • Object methods are activated via message passing • Data can be passed via • Argument list • Globally scoped variables • Receiver scoped variables

5. Objects • In an Object-Oriented design, attributes and behaviors are grouped together into a single container • Attributes are data items (member variables) • Behaviors are methods (member functions) • The container is the class • Avoid global data and functions • Data and functions that are declared outside any class • Some OO languages do not even allow this (Java)

6. Data Hiding • Access to class methods and attributes should be restricted • Attributes should be private • Access to attributes is provided by • Accessors (“getters”) • Mutators (“setters”) • Behaviors may be public or private, depending on their functionality • Public methods are message handlers • Only the interface is exposed to the “outside world” • Implementation details are hidden • Private methods are helpers • Existence is completely withheld from the “outside world”

7. Class and Object • A class is a high-level data item (abstract data type) that will be useful in designing your software but not supplied natively by the language • A class has no physical existence • Objects are the data items instantiated (declared) of type class • An object has a physical existence in computer memory

8. Attributes • Can be native (primitive) data types (int, double, float, char, …) • Can be abstract data types (class) • Should be private

9. Methods • Constructors – for initialization of the newly instantiated object • Destructor (C++) – for clean-up of an unneeded object (finalize in Java) • Message handlers – publicly accessible for communication among objects • Helpers – private functions for use within the object

10. Encapsulation • Interface • The type-signature of the message handlers • Name, argument types, return type • May be a language specific construct as in Java • May be a header file as in C++ • VB??? C#??? • Implementation • The code that performs the desired task • Hidden from the outside world

11. Composition/Aggregation • A form of code reuse • Break a large object into small objects that may be useful in other places • Easier to • Understand • Design • Implement • Debug • The “has-a” test is used to determine if an aggregation relationship between two classes is appropriate

12. Inheritance • Another form of code reuse • Grouping of attributes and behaviors that are common to two or more classes • The common attributes/behaviors are formed into a class called the base class, super class, or parent class • New classes may extend the base class to include additional functionality not common to other classes • Called the Derived class, sub-class, or child class • The “is-a” test is used to determine if an inheritance relationship between two classes is appropriate

13. Inheritance • An inheritance tree or inheritance hierarchy is formed by deriving new classes from the previously derived classes – all with heritage (ancestry) back to the root class • Some languages (C++) allow for multiple inheritance – Java does not [directly] • What problems arise with multiple inheritance?

14. Polymorphism • A single message that can be handled by anyone of a number of message handlers • The specific message handler is determined by the context of the message • The determination is made at run time (unless the compiler can do it based on the type-signature of the message) • Inheritance relationships can cause confusion • Object-oriented languages usually offer some form of real-time-type-identification (RTTI)

15. Object-Oriented Design Process(actually, all design processes) • Conceptualization • Analyze the problem specification • Identify primary classes and their relationships • Representation • Model the system • Refine classes (change, add, delete) • Implementation • Convert the model to code

16. Conceptualization • Make sure you understand the given task before you start working on it • Read the specification • Ask the customer/user questions • Create informal scenarios • Identify useful classes/objects • Clear up any ambiguities that may exist • Create UML Use Case diagrams • Identify test cases to validate proper system operation • Present your understanding to the team (informal walk-thru) and to the customer (structured walk-thru)

17. Representation • Create a model of the system • Unified Modeling Language • Class diagrams • Interaction diagrams • Sequence • Collaboration (Communication) • State diagrams • Deployment diagrams • Others as necessary • Code prototypes • How detailed should the UML be? • Sketch • Blueprint • Programming Language

18. Implementation • Convert models (UML diagrams) to code • Class skeletons • Method signatures • Pseudo code (comments) • Operational programs

19. Use Case Diagram Chapter 9

20. Informal Scenario • When there are parts of the system… • …that you just don’t understand by reading the specification… • …that are obvious from reading the specification… • …you should “play computer” • This is what informal scenarios are for

21. Informal Scenario • Describe in excruciating detail, exactly how the system (hardware + software + user) operates under various conditions • Cover a very small “snippet” of the system operation • They are not beginning-to-end descriptions! • If you make enough informal scenarios, you could conceivably link them together to make a beginning-to-end description

22. X O X O X O X O O Informal Scenario • Consider a tic-tac-toe game Title: End-Game Current State: X has markers in the upper-left and right squares O has markers in the upper and middle-middle squares It is O’s turn Scenario: O places a marker the lower-middle square Seeing that O has three of its markers unblocked, horizontally, in the middle column O declares itself the winner X concedes defeat Next Scenario(s): 1) Request rematch 2) Throw tantrum

23. Informal Scenario • Guidelines • Should be short • Should address only one system activity • Should utilize specific/concrete values • Should address pass (expected behaviors) and fail (unexpected behaviors) situations • Should not contain implementation details • Should describe the state of the system going into the scenario • Should indicate the next scenario(s)

24. Informal Scenario • Bad scenario: Title: End-Game Current State: X has two markers on the board O has two markers on the board Scenario: O places another marker on the board O declares itself the winner because it has three markers in a row Next Scenario(s): 1) Request rematch 2) Throw tantrum

25. Scenario • A scenario is a sequence of informal scenarios chained together to describe an end-to-end behavior of the system • Note that depending on how informal scenarios are chained together, multiple scenarios can be created

26. Use Case • Capture the functional requirements of a system • Describe typical interactions between the users and the system • Users may be people, data sources, or other systems • Represent a set of scenarios that are of similar functionality (but may differ in their detail)

27. UML • Does not provide any diagrams or guidelines for developing informal scenarios or scenarios • Does provide facilities for creating use case diagrams

28. Use Case Diagram System boundary Use cases Actor Actor Use cases

29. Use Case Diagram • It’s merely a graphical representation of the functions performed by the system • Don’t try to add a lot of detail to them, just capture the essence of the system functionality • Detail will come in later diagrams • You can think of the Use Case Diagram as a “table of contents” and the other diagrams to be the “content”

30. Project Deliverables • Write a formal specification document including my functional specifications and the answers I gave to your questions • Due next class meeting (Deliverables continued on next page)

31. Project Deliverables • Create informal scenarios • Create scenarios • Create a use case diagram • Note that this is probably a very simple diagram since we are designing a very simple system • Due week after next (I want to see progress next week and answer any questions you may have)