cs 322 software engineering - knox...
TRANSCRIPT
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.
Object Oriented Design 3
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.
Object Oriented Design 4
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
Object Oriented Design 5
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
Object Oriented Design 6
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.
Object Oriented Design 7
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)
Object Oriented Design 8
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
Object Oriented Design 9
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
Object Oriented Design 10
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)
Object Oriented Design 11
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 Design 12
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
Object Oriented Design 13
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
Object Oriented Design 15
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.
Object Oriented Design 16
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.
Object Oriented Design 17
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.
Object Oriented Design 19
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.
Object Oriented Design 22
The feature list
• What features or requirements can we extract from the problem statement?
Object Oriented Design 24
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
Object Oriented Design 25
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
Object Oriented Design 26
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
Object Oriented Design
So, for the Route Finderwe can get...
...and what we do nextis to assign featuresto the use cases...
Object Oriented Design
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.
Object Oriented Design
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
Object Oriented Design 30
Use Cases
• What other use cases do we have?• What’s in them?
Left as an exercise for the interested reader.
Object Oriented Design 31
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!
Object Oriented Design
• So given the use cases we’ve identified how might we break up the system?
32
Object Oriented Design 33
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...
Object Oriented Design
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.
Object Oriented Design
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?
Object Oriented Design
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.
Object Oriented Design
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
Object Oriented Design 42
Now, objects!
• Next step is to identify objects that exist in your use cases.
Object Oriented Design 43
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.
Object Oriented Design 44
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.
Object Oriented Design 45
• 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 Oriented Design 46
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.
Object Oriented Design 48
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?
Object Oriented Design 49
Class diagrams
Class Name
Attributesname: type
Methodsname(parameters): return type
Ack! More UML!
Object Oriented Design 51
Iteration 2… What’s next?
We’ve finished one of the use cases we came up with, what’s next?
Object Oriented Design 55
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.
Object Oriented Design 56
The 23 things to remember about class design
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.
Object Oriented Design 57
The 23 things to remember about class design
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.
Object Oriented Design 58
The 23 things to remember about class design
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…
Object Oriented Design 59
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).