cs 322 software engineering - knox...

Object Oriented Design 1

Software Developmentand Professional Practice

Object-Oriented Analysis & DesignPart the First - An Overview

(in which we go over all the features of OOA&D in brief)

Intro to Development 2

Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

A number of slides in this file contain figures and data from Head First Object-Oriented Analysis and Design, and are copyrighted by O’Reilly Media, Inc., 2007.

http://creativecommons.org/licenses/by-nc-sa/3.0/

http://creativecommons.org/licenses/by-nc-sa/3.0/


Now it’s time to start reading Head First Object-Oriented Analysis and Design

Read Chapters 1 - 3, 8 and 10 to begin with.

And Dooley, Chapter 8.


Objectives

• To talk about OO Analysis and Design• To describe the activities in the object-oriented

design process• To introduce some models that describe an

object-oriented design• To talk about object-oriented design principles• To introduce the UML modeling language

• well, kinda, sorta• To talk about agile practices and OOA&D


Objects review in < 30 seconds

• Objects are things.

• They have an identity (i.e. a name), state, and a defined set of operations that operate on that state.

• Classes are templates for objects.• Classes can also be thought of as factories

that generate objects.

• Classes may inherit attributes and services from other object classes


Well, OK, < 60 seconds

• Objects operate by passing messages to methods inside other objects (or even themselves).

• Objects use encapsulation to isolate data and operations.

• There are accessor and mutator methods used to work with the data in an object.• although we will see there are limitations

• Shared data areas are (usually) eliminated.


OK, < 90 seconds

• Objects are members of classes which define attribute types and operations

• Classes may be arranged in a class hierarchy where one class (a super class or base class) is a generalization of one or more other classes (sub-classes)


inheritance

• A sub-class inherits the attributes and operations from its super class and may add new methods or attributes of its own.

• In this sense a sub-class is more specific and detailed than it’s base class.

• In Java this is called inheritance

• in UML it’s called generalization


Advantages of inheritance

• It is an abstraction mechanism which may be used to classify entities

• It is a reuse mechanism at both the design and the programming level

• The inheritance graph is a source of organizational knowledge about domains and systems


Problems with inheritance

• It makes object classes that are not self-contained. They cannot be understood without reference to their super classes

• Inheritance introduces complexity and this is undesirable, especially in critical systems

• Inheritance also usually allows overloading of operators (methods in Java) which can be • good (polymorphism) or • bad (screening useful methods in the superclass)


Advantages of O-O programming

• Easier maintenance. Objects may be understood as stand-alone entities

• Objects are appropriate reusable components

• BUT, for some problems there may be no obvious mapping from real world entities to system objects

• Implying that object-oriented systems may not be appropriate for all problems.

• I am shocked! just shocked!


Object-oriented Analysis• Object-oriented analysis, design and programming

are related but distinct

• OOA is concerned with developing an object model of the application domain• so, for example you take the problem statement

• generate a set of features and (possibly) use cases

• tease out the objects and some of the methods within those objects that you’ll need to satisfy the use case

• you put together an architecture of how the solution will hang together.

• that’s OOA


OO Design

• OOD is concerned with developing an object-oriented system model to satisfy requirements

• You take your objects generated from your OOA

• figure out whether to use inheritance, aggregation, composition, abstract classes, interfaces, etc.

• draw the class diagrams and flesh out the details of what each attribute is and what each method does.

• describe the interfaces

• that’s the design

Object Oriented Design

OO Programming (aka OOPs)

• OOP is concerned with implementing an OOD using an O-O programming language such as Java, Smalltalk, C#, Python, or C++

• Write tests that will exercise your design.

• Take your OOD and code it

• run the tests; if they pass, move on to the next iteration

• if they fail, well, figure out what went wrong.

14


An OOA&D Process

1. Write (or receive) the Problem Statement2. Create the Feature List3. Write up Use Cases4. Break up the Problem5. Do domain analysis6. Identify Objects, Methods, and algorithms7. Implement this iteration8. Test the iteration9. If you’ve not finished the feature list, go back to

step 5, otherwise10. Do final acceptance testing and release.


An OOA&D Process (with references)

Most of this stuff from Ch 10 of OOA&D1. Problem Statement (pg. 62, 488)2. Feature List (pg 493)3. Use Cases (pg 72, 495, and Ch3 pg 111)4. Break up the Problem (pg 501)5. Do domain analysis (pg 510)6. Identify Objects, Methods, and algorithms (pg 510 - 515)7. Implement this iteration (pg 516)8. Test the iteration (pg 527)9. If you’ve not finished the feature list, go back to step 5,

otherwise10. Do final acceptance testing and release.


OOA&D and the software life cycle• Requirements (well, Analysis)

1. problem statement2. feature list3. use cases

• Design4. Break up the Problem5. Do domain analysis6. Identify Objects, Methods, and algorithms

• Implementation7. Implement this iteration8. Test the iteration9. If you’ve not finished the feature list, go back to step 5, otherwise

• Release/Maintenance/Evolution10. Do final acceptance testing and release.


The process in review

18


Requirements

• the problem statement

• the feature list • your response to the problem statement• all about understanding what your software is supposed

to do

• use case diagrams• let you start thinking about how the software will be

used without thinking about lots of details.• use cases get generated from the diagrams. They are

the next level of detail.


The problem statement

pg. 488

The Map is on thenext slide. (pg. 490)


The feature list

• What features or requirements can we extract from the problem statement?


8

Feature list for the Route Finder

1

2

3

4

5

6


Use Cases

• once you have a feature list, you can create one or more use cases.

• Why?• because you need to really understand what the

software will do• and a set of use cases will let you walk through

the software from the user’s perspective• and because the use cases will help you tease out

more requirements


But wait...

• sometimes you get bogged down in details when you write use cases too early

• so....

• start with use case diagrams• they’ll help you find the “big picture”• they’re another UML feature


Use CaseDiagrams

Take featuresfrom yourfeature list andmake use cases here.

The little guysare “actors” (they are outside the system)

each oval is asingle use casein the system.

We’ll expand them later.

The system

actors

pg 496


So, for the Route Finderwe can get...

...and what we do nextis to assign featuresto the use cases...


The system is able to model the subway system.

The system must be able to represent multiple, overlapping lines.The system can compute a valid path between any two stops.

The system can print (display) a route.

The system must be able to indicate where passengers should change trains on a route.


Use Case: Find Route

1. Traveler enters starting station and final destination (this is likely NOT a station)

2. Traveler enters starting and final station3. Traveler selects option to find shortest route or

route with fewest transfers4. System calculates a route from the starting and

final station5. System produces a route as a sequence of stations

or as a map, with route highlighted.6. User requests a printout and system prints the

route

23


Use Cases

• What other use cases do we have?• What’s in them?

Left as an exercise for the interested reader.


Break up the System• Take the use case diagram & the feature list and

break the system up into smaller modules• these are not classes yet• they are bigger pieces that represent larger bits

of functionality!


• So given the use cases we’ve identified how might we break up the system?

32


Now, where’s that use case?

• Now that we’ve got the big system broken up into modules, we can see about devising more individual use cases!

Wait a minute? We don’t know how the subway would be represented. How can we detail this

use case?

Here’s a case of where we need to stopand think about the data and how it influencesthe object design. So think for a second...


Time for a spike

17

What’s a spike, you ask??

A spike is an experiment (including a thought experiment) that allows developers to learn just enough about something unknown in a user story or use case to be able to model and/or estimate that user story.


What is a subway system?

18

A subway system is a collection of lines. Each line has a unique name and consists of a set of stations that are connected to each other by subway tracks. The trains run between the stations in both directions.

Any station on a line may connect to one or more other stations on that line. Also, lines may share stations. This allows a passenger to transfer from one line to another.

A passenger may go from any station to any other station in the system. This may require zero or more transfers.

Now, how much does this help us with the analysis?


Textual analysis

19

A subway system is a collection of lines. Each line has a unique name and consists of a set of stations that are connected to each other by subway tracks. The trains run between the stations in both directions.

Any station on a line may connect to one or more other stations on that line. Also, lines may share stations. This allows a passenger to transfer from one line to another.

A passenger may go from any station to any other station in the system. This may require zero or more transfers.


• What objects are here and how might they interact with each other?

37


What we know‣ Stations are the key

‣ We need to know what other stations each station can connect to

‣ We need to know what lines a station serves

‣ We need to be able to find a path from one station to another

‣ These are things at the next level of detail; we’re starting to think about the architecture and design of the system now.

25


A possible route finding model

15


One level down - possible subway models

20


pg 508


Now, objects!

• Next step is to identify objects that exist in your use cases.


Object identification

• Identifying objects (or object classes) is a difficult part of object oriented design

• There is no 'magic formula' for object identification. It relies on the skill, experience and domain knowledge of system designers (that would be you)

• Object identification is an iterative process. You are not likely to get it right the first time

• We’ve already done one type of object identification - textual analysis.


Approaches to identification

• Base the identification on tangible things in the application domain (like nouns)

• Use a behavioral approach and identify objects based on what participates in what behavior (use verbs)

• Use a scenario-based analysis where the objects, attributes and methods in each scenario are identified from the corresponding use case• Remember, a scenario != a use case

» A scenario is one way through a use case.


• Objects manifest themselves in a number of ways:

• External entities that produce or consume information.

• Things that are part of the information domain (reports, displays, etc.)

• Occurrences or events that occur within the system

• Internal producers (objects that make something)

• Internal consumers (objects that consume what producers make)

• Places (remote systems, databases, etc.)

• Structures (windows, frames)


Object Selection Characteristics• Required information

• The object must have information that must be remembered so the system can function.

• Needed services• The object must provide services relating to the

system goals.• Common attributes

• The attributes defined for the object must be common to all instances of the object.

• Common operations• The operations defined for the object must be

common to all instances of the object.


So what objects do we have?

• InterestingSite

• Station

• Connection

• Subway

• Subway Line (maybe)

• Subway Loader (sort of the top level class here)

• What attributes and methods does each class have?


Class diagrams

Class Name

Attributesname: type

Methodsname(parameters): return type

Ack! More UML!


Iteration 2… What’s next?

We’ve finished one of the use cases we came up with, what’s next?


pg 498


37


• Now lets look at another example...• an old familiar one...Tickets!

54


The 23 things to remember about class design

1. Present a consistent level of abstraction in the class interface.

2. Be sure you understand what abstraction the class is implementing.

3. Move unrelated information to a different class

4. Beware of erosion of the class’s interface when you are making changes.

5. Don’t add public members that are inconsistent with the interface abstraction.

6. Minimize accessibility of classes and members.



7. Don’t expose member data in public.

8. Avoid putting private implementation details into the class’s interface.

9. Avoid putting methods into the public interface.

10. Watch for coupling that’s too tight.

11. Try to implement “has a” relations through containment within a class.

12. Implement “is a” relations through inheritance.



13. Only inherit if the derived class is a more specific version of the base class.

14. Be sure to inherit only what you want to inherit.

15. Move common interfaces, data, and operations as high in the inheritance hierarchy as possible.

16. Be suspicious of classes of which there is only one instance

17. Be suspicious of base classes that only have a single derived class.

18. Avoid deep inheritance trees.



19. Keep the number of methods in a class as small as possible.

20. Minimize indirect method calls to other classes.

21. Initialize all member data in all constructors, if possible.

22. Eliminate data-only classes.

23. Eliminate operation-only classes.

24. Oh, and be careful out there…


References• McLaughlin, et. al., Head First Object-Oriented

Analysis & Design, 2007. (Chapter 10)• Some slides Copyright 2006 by Ian Sommerville.• Sommerville, Ian, Software Engineering, 6th ed.,

Addision-Wesley, 2000, (Chapter 12).• McConnell, S., Code Complete, 2nd edition, Microsoft

Press, 2004, (Chapter 6).• Fowler, M., UML Distilled, 2nd edition, Addison-

Wesley, 2000, (Chapters 1 through 5).• Alhir, S., UML in a Nutshell, O’Reilly & Associates,

Inc., 1998, (Chapter 4) (but really not a good book).

cs 322 software engineering - knox...

Documents