1 / 15

CSC 213 – Large Scale Programming

CSC 213 – Large Scale Programming. Lecture 2: Object-Oriented Analysis & Object-Oriented Design. Today’s Goal. Discuss traits that make programmers great Learn Unified Process to design programs “Types” of Java classes Methods of selecting the potential classes

Download Presentation

CSC 213 – Large Scale Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CSC 213 –Large Scale Programming Lecture 2: Object-Oriented Analysis & Object-Oriented Design

  2. Today’s Goal • Discuss traits that make programmers great • Learn Unified Process to design programs • “Types” of Java classes • Methods of selecting the potential classes • Models which test if the class design will work

  3. Secrets to Success • What separates the good from the great: • Innate intelligence? • Decades of experience? • Eating cans of spinach before class? • Habits, traits, & skills of great programmers:

  4. Designing Programs • Designing a program is hard • Good design makes the programming simple • May not be able to implement a bad design • Design also easiest stage to make changes • Need not worry about implementation issues • Changes are simple; only requires an eraser

  5. Designing Programs • Ultimately, program design like any other skill • What’s the quickest way to Carnegie Hall? • Get many opportunities with this in CSC213 • Will begin discussion today & Monday • Unified Process helps develop design • Begins by figuring out the potential classes • Figures out methods needed for each class • Exposes design problems before writing code

  6. 3 “Types” of Classes • Unified Process concept to simplify designs • Entity classes hold the long-lived data • Boundary classes defined for input & output • Control classes do complex processing in the program • “Types” exist only for purposes of design • Within Java, a class is a class is a class

  7. Entity Classes • Design starts with program requirements • In a class, this is the assignment handout • Noun extraction finds entity classes • Identify nouns in requirements – these are the candidate classes • Eliminate classes that are external to problem • Ignore abstract nouns (nouns that do not define a physical object) and nouns used in communication • Usually become fields or boundary classes

  8. Designing Elevator Controller Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Identify the nouns in the requirements Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Eliminate classes external to the problem Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Ignore Abstract Nouns Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Button, Elevator, Floor

  9. Boundary Classes • Boundary class exists for each input & output • Inputs and outputs are often complex • May record many individual details • Each detail defines own boundary class • Boundary class also defined for record • Go from simplest classes to complex class • Complex class just has fields of simple class • Much harder to break complex class up into simple classes

  10. Designing Elevator Controller Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Each input and output is a boundary class Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Movement, Illumination, Request Each input and output is a boundary class Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

  11. Skipping Boundary Classes • Boundary classes may duplicate primitive type • Illumination is on or off • Movement is up or down • Both of these are boolean • Can skip defining classes duplicating primitive • Hard-code primitive throughout the code • Saves javadoc for class, field, getter & setter • But if you need to make a change, must find code to change and/or replace all the primitives • Nearly always ends up worth writing the class

  12. Control Classes • Defined for each non-obvious algorithm that uses multiple items • What is “non-obvious” is not always… obvious • Rule of thumb: algorithm is non-obvious if algorithm is not named in the assignment • Defined for all plural nouns in requirements • If exact number known, can use an array • Otherwise need collection class of objects • Depending on access pattern, may want Stack, ArrayList, Dictionary, Set, …

  13. Designing Elevator Controller Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Skip plurals with exact count Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. Buttons, Requests Non-obvious algorithms or plurals Buttons in elevators and on the floors control the movement of nelevators in a building with mfloors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

  14. Daily Activity Design classes needed for a tic-tac-toe controller: Game is played on a board. The board is a 3-by-3 grid of squares. Game has 2 players alternately making a move. For a move, a player selects a square. If the selected square is not empty, the player loses. Otherwise, the square is marked for the player. A player wins if they mark a line of 3 squares. If the entire board is marked without a player winning, the game is a tie.

  15. For Next Lecture • Will finish design discussion on Monday • Illustrate a design using a language called UML • Converting between UML and Java • Test to see if the design works and makes sense • Debugging methods when a design does not work

More Related