1. Object-Oriented Analysis and Design NGSSC Object-Oriented Scientific Programming, June 2012

2. Object-Oriented Software Construction  Program = Data + Algorithm  Constructing a software program can be seen as building a model.  Structured programming (the 70s) focused on modelling algorithms, whereas OOP has its focus on modeling data.  Data is often more stable than algorithms, which makes OO models easier to change.  Data is more tangible, which makes OO models easier to understand.

3. History of the Object-Oriented Approach Languages: 1969 Simula 1972 Smalltalk 1985 C++ 1990 Python 1995 Java Methods and notation: 1991 Booch 1991 OMT Rumbaugh et al 1992 OOSE Jacobsen Unified Modeling Language: 1995 UML 0.9 2002 UML 1.4

4. Example: Matrix addition Traditional version: a and b are a two-dimensional arrays for i = 0, lines for j = 0, cols a(i, j) = a(i, j) + b(i, j) end for

5. Example: Leap-Frog ADT version a and b are variables of type Matrix a = a.add(b)

6. Traditional vs. Object-Oriented Software Data structures visibleData structures hidden Focus on a problemFocus on a problem domain TraditionalObject-oriented

7. Key concepts  Object  Class  Encapsulation  Operation  Inheritance  Polymorphism  Method

8. Some advantages  Faster code development (due to reusable components)  Easier to maintain and modify (due to encapsulation and inheritance)  Easier to scale programs (due to modelling and inheritance)  Easier communication with non-computer scientists

9. Object-Oriented Modeling Two phases:  Analysis  Design Two views:  Structural/static  Behavioural/dynamic

10. Structural/Static Modeling Structural model: a view of a system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations. No temporal information!! We will use class diagrams to express the structural model

11. Building a class diagram  Identify classes  Begin a data dictionary  Add associations between classes  Add attributes  Look for inheritance relations  Test the model via scenarios, and iterate the above steps as necessary

12. Finding classes Phase 1: brain storming List concepts in the problem domain Include anything that comes to your mind Phase 2: selection Remove candidates that are: redundant, irrelevant, vague, attributes, operations, associations, roles, implementation constructs, et cetera

13. Class Fig. 3-20, UML Notation Guide

14. Class and objects Point x: Real y: Real rotate (angle:Real) scale (factor:Real) p1:Point x = 3.5 y = 2.7 :Point x = 1 y = -1

15. Associations Fig. 3-40, UML Notation Guide

16. Special Associations: Aggregations and Composites Fig. 3-41, UML Notation Guide

17. Inheritance Fig. 3-47, UML Notation Guide

18. Constraints and Comments Fig. 3-17, UML Notation Guide Member-of Chair-of {subset} PersonCommittee PersonCompany boss {Person.employer = Person.boss.employer} employeremployee 0..1     1 Represents an incorporated entity.

19. Structural Modeling Tips  Define a “skeleton” (or “backbone”) that can be extended and refined as you learn more about your domain.  Focus on using basic constructs well; add advanced constructs and/or notation only as required.  Defer implementation concerns until late in the modeling process.

20. When to model use cases  Model user requirements with use cases.  Model test scenarios with use cases.  If you are using a use-case driven method:  start with use cases and derive your structural and behavioral models from it.  If you are not using a use-case driven method:  make sure that your use cases are consistent with your structural and behavioral models.

21. Behavioral/Dynamic Modeling with UML xyz Sequence Diagram a b c Collaboration Diagram xy z 1.1: a 1.2: c 1.1.1: b

22. Use Case: Change Flight Itinerary Actors: traveler, client account data base, airline reservation system Preconditions: Traveler has logged in Basic course: –Traveler selects ‘change flight itinerary’ option –System retrieves traveler’s account and flight itinerary from client account database –System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. –System asks traveler for new departure and destination information; traveler provides information. –If flights are available then … –… –System displays transaction summary. Alternative course: –If no flights are available then…

23. Sequence Diagram: Change Flight Itinerary : Booking SystemTravelerAirline Reservation System change flight itinerary get customer account get itinerary present itinerary select segment present detailed info update information available flight: Client Account DBMS

24. Collaboration Diagram: Change Flight Itinerary TravelerClient Account DBMSAirline Reservation System : Booking System 7: update information 2: get customer account 3: get itinerary 4: present itinerary 8: available flight 1: change flight itinerary 5: select segment 6: present detailed info

25. Design patterns A systematic way of describing a solution to a modeling problem Four key elements: 1.Pattern name 2.Problem description 3.Solution 4.Consequences