ObjectOriented Analysis and Design NGSSC ObjectOriented Scientific Programming

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

Object-Oriented Software Construction § Program = Data + Algorithm § Constructing a software program can be seen as building a model. § Structured programming (the 70 s) 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.

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

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

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

Traditional vs. Object-Oriented Software Traditional Object-oriented Data structures visible Data structures hidden Focus on a problem domain

Key concepts § § § § Object Class Encapsulation Operation Inheritance Polymorphism Method

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

Object-Oriented Modeling Two phases: § Analysis § Design Two views: § Structural/static § Behavioural/dynamic

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

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

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

Class Fig. 3 -20, UML Notation Guide

Class and objects Point x: Real y: Real p 1: Point x = 3. 5 y = 2. 7 rotate (angle: Real) scale (factor: Real) : Point x=1 y = -1

Associations Fig. 3 -40, UML Notation Guide

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

Inheritance Fig. 3 -47, UML Notation Guide

Constraints and Comments * Member-of * Person 1 * 0. . 1 boss Committee {subset} Person Chair-of * employee * employer 0. . 1 Represents an incorporated entity. Company {Person. employer = Person. boss. employer} Fig. 3 -17, UML Notation Guide

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.

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.

Behavioral/Dynamic Modeling with UML Sequence Diagram x y Collaboration Diagram z 1. 1: a 1. 2: c x a y b 1. 1. 1: b c z

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…

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

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

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