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

Transcription

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 Python 1995 Java Methods and notation: 1991 Booch 1991 OMT Rumbaugh et al 1992 OOSE Jacobsen Unified Modeling Language: 1995 UML 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 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 Traditional Object-oriented Data structures visible Data structures hidden Focus on a problem Focus on a problem domain

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 Window Window size: Area visibility: Boolean display () hide () Window {abstract, author=joe, status=tested} +size: Area = (100,100) #visibility: Boolean = true +default-size: Rectangle #maximum-size: Rectangle -xptr: XWindow* +display () +hide () +create () -attachxwindow(xwin:xwindow*) 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 x = 1 y = -1 :Point

15 Associations Company Job employer employee Person Job salary worker boss 0..1 Manages Person Account {Xor} Corporation Fig. 3-40, UML Notation Guide

16 Special Associations: Aggregations and Composites Polygon 1 1 +vertex Contains 3.. {ordered} 1 -bundle Point GraphicsBundle color texture density Fig. 3-41, UML Notation Guide

17 Inheritance Shape Separate Target Style Polygon Ellipse Spline... Shape Shared Target Style Polygon Ellipse Spline... Fig. 3-47, UML Notation Guide

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

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 Sequence Diagram Collaboration Diagram x y z a x 1.1: a 1.2: c y c b z 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 Traveler change flight itinerary : Booking System get customer account Client Account DBMS Airline Reservation System present itinerary get itinerary select segment present detailed info update information available flight : :

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

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