Object-Oriented (OO) Design

Slides:



Advertisements
Similar presentations
Unit 251 Summary  Requirements may be represented in itemized format or in visual modeling (UML). Once the complete set of requirements are in our hand,
Advertisements

OBJECT ORIENTED PROGRAMMING M Taimoor Khan
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
1 CSE1301 Computer Programming: Lecture 23 Algorithm Design (Part 1)
Representing a Game Board In a game, we represent the action taking place using an array – In a very simple game, we use individual variables to represent.
Chapter 1 Object-Oriented System Development
Object Oriented System Development with VB .NET
The Architecture Design Process
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
Lecture 4 Class Responsibility Collaboration Cards
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
NJIT 1 Domain Model Visualizing Concepts Chapter 9 Applying UML and Patterns Craig Larman.
Object-Orientated Design Unit 3: Objects and Classes Jin Sa.
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
The chapter will address the following questions:
Objects What are Objects Observations
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities.
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Architecture GRASP Realization of use cases in interaction diagrams Design class diagram Design ( how )
Detailed design – class design Domain Modeling SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
More on “The Huddersfield Method” A lightweight, pattern-driven method based on SSM, Domain Driven Design and Naked Objects.
Chapter 17. Initial Object Design Inputs: requirements meetings various Use Cases – 10% complete Key risks addressed with preliminary programming System.
11 Partnership for Performance How to hear this lecture Click on the icon: to hear the narration for each slide.
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Design Patterns. Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Patterns and Reuse. Patterns Reuse of Analysis and Design.
GRASP: Designing Objects with Responsibilities
CS Overview of CRC CS 4311 B. Beck and W. Cunningham, A Laboratory for Teaching Object-Oriented Thinking, OOPSLA ’89, October 1-6, R. Wirfs-Brock,
Chapter 9 Applying UML and Patterns -Craig Larman
ITEC324 Principle of CS III Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee.
Internet and Intranet Protocols and Applications Lecture 5a: HTTP Client-Server Design and Implementation February 15, 2005 Arthur Goldberg Computer Science.
CMSC 202 A Design Exercise. 2 OO design activities Finding the Objects Defining the responsibilities –Services –Attributes Discovering relationships.
Design. Practices Principles Patterns What are the characteristics of good design? What are good solutions to common design problems? How do we go about.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
Identification of Classes. Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements.
What is this? SE-2030 Dr. Mark L. Hornick 1. Same images with different levels of detail SE-2030 Dr. Mark L. Hornick 2.
General Principles in Assigning Responsibilities Responsibilities Responsibility-Driven Design CRC Cards GRASP.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
Advanced Higher Computing Science
An informal, team oriented, OO design system
Elaboration popo.
GRASP – Designing Objects with Responsibilities
Classes and their relationships
Chapter 4: Business Process and Functional Modeling, continued
Intro to Computer Science II
Next Level Tic-Tac-Toe
Chapter 12: Collaboration Diagram - PART2
Conception OBJET GRASP Patterns
The Object-Oriented Thought Process Chapter 1
Creation of an Android App By Keith Lynn
OO Domain Modeling With UML Class Diagrams and CRC Cards
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
Chapter 6 : Game Search 게임 탐색 (Adversarial Search)
Chapter 10 Requirements Modeling: Class-Based Methods
CIS 375 Bruce R. Maxim UM-Dearborn
OBJECT ARCHITECTURE DESIGN
Basic OOP Concepts and Terms
Chapter 22 Object-Oriented Systems Analysis and Design and UML
CIS 375 Bruce R. Maxim UM-Dearborn
ITEC324 Principle of CS III
Backtracking, Search, Heuristics
ITEC324 Principle of CS III
Unit II Game Playing.
Logical Architecture & UML Package Diagrams
Object Oriented System Design Responsibilities
Design & Development – 2h
Presentation transcript:

Object-Oriented (OO) Design CSE 5236: Mobile Application Development Course Coordinator: Dr. Rajiv Ramnath Instructor: Adam C. Champion, Ph.D. Reading: Applying UML and Patterns, Chaps. 1, 6 (OO ref.); Big Nerd Ranch Guide, Chap. 2 (Android/MVC)

Elements of Good OO Design Idea: Capture complexity of real-world problems, solutions via objects Classes and responsibilities Polymorphism helps represent the real-world Achieve system goals through collaboration Principles: Loose coupling, high cohesion Abstraction Encapsulation, information hiding Methodology: Scenario-Driven Design Implement objects needed for vertical slices of system Technique: CRC-Card-Based Design

You should know what each term means! Terminology Check Class Object Method Function Class method Subclass (implementation) Subtype (interface) Interface Abstract class Virtual method You should know what each term means!

OO Design Process Capture narratives of the environment, application (app) Via observations, talking with domain experts, stakeholders, end users Identify specific “circumstances” where an app would be used Capture using text, storyboards, sketches Identify domain classes, assign responsibilities; collaborators Evaluate using OO Checklist Develop the application flow: use cases, screen flows Map domain model to Android framework model Map app flow to framework model; connect UI to domain model; identify collaborators, update model/flow Add contracts Evaluate using OO Checklist (again)

Identify Objects and Classes Examine nouns, noun phrases as candidates Adjectives: candidate attributes or subtypes Group into categories: potential abstract classes, superclasses Write down the purpose of each class Eliminate redundant or non-domain classes

Identify, Assign Responsibilities Start with verbs and verb phrases (i.e. actions) Assign to the appropriate classes Distribute evenly: don’t give one class too much work Don’t break the class definition Locate responsibility with information Locate related information together

Map Domain Model to Framework Patterns Usually a variation of MVC

Identify Collaborations Examine narratives, storyboards, use cases Create scenarios Walkthrough scenarios Identify interactions between classes These are the collaborations

Evaluate Using Design Checklist Each class must have: Clear name Cohesive description of responsibility Long-lived state Collaborators

Record on CRC Cards (1) Source: K. Beck and W. Cunningham, “A Laboratory For Teaching Object-Oriented Thinking,” Proc. ACM OOPSLA, 1989. http://c2.com/doc/oopsla89/paper.html

Record on CRC Cards (2) Sources: K. Beck and W. Cunningham, “A Laboratory For Teaching Object-Oriented Thinking,” Proc. ACM OOPSLA, 1989; C. Larman, Applying UML and Patterns, 3rd ed., Addison-Wesley, 2004.

Exercise: Tic-Tac-Toe Tic-tac-toe, also spelled tick-tack-toe, or noughts and crosses, as it is known in the UK, Ireland, Australia, New Zealand, is a pencil-and-paper game for two players, who take turns marking the spaces in a 3×3 grid with the symbols X and O respectively. The X player usually goes first. The player who succeeds in placing three respective marks in a horizontal, vertical, or diagonal row wins the game. Extend this by adding a narrative about playing the game on an Android device: Tic-tac-toe for Android will implement the Tic-tac-toe paper game as an Android app. In it, human users will be able to play Tic-tac-toe against the computer. Multiple games may be played in each session, with either the computer playing first or the human playing first on an electronic board that will be displayed on the device’s touch screen. Scores for each session will be accumulated. If the user quits the session, scores will be reset.

Nouns and Verbs Nouns: pencil, paper, game, nought, cross, player, X, O, space, symbol, grid, mark, vertical row, horizontal row, diagonal row, human user, human, computer, session, board, touchscreen, score. (Candidate objects and classes) Verbs: take turn, mark, goes, place, win, implement, play, playing first, display, accumulate, quit, reset. (Candidate responsibilities)

Consolidate: Nouns Remove pencil, paper, touchscreen – physical objects Symbol and mark identical – retain symbol. User vs. player – retain player Remove one of board and grid Remove touchscreen – physical Row is a component Session is an instance of game Remove “pencil” and “paper” as physical things not relevant to an Android-based game. Observe that “symbol” and “mark” are identical and retain “symbol.” Observe that “nought” and “O” and “cross” and “X” are identical and, being from the U.S. of A, remove the hated British monstrosities, and leave “O” and “X”. Further note that “O” and “X” appear to be either instances or sub-classes of Symbol. Compare “User” and “Player”. Retain “player” as the player in the game (and note that the “user” is the person using the Android device). Note that “human user” and “human” might be identical concepts, and further that they as well as “computer” are instances or sub-classes of “player.” Realize that “board” and “grid” close enough in meaning that one of them could be removed. We decide to keep “grid,” and, in fact rename it to “game grid.” What about “touch screen?” Since it appears to refer to a physical component of the phone, a first inclination might be to remove it. On the other hand, something needs to handle the visual display of the board. It could be the board itself, or we could separate the data structure that represents the board from its visual manifestation. So that is what we decide to do. But we rename it to Board so as to address our first issue with it. Consider “row” as a component of “game grid,” and “vertical row,” “diagonal row” and “horizontal row” as essentially being different sub-classes or instances of “row”; we don’t know which yet. Consider “session” as being an instance of “game,” with “score” being an attribute of either the “game” or the two players.

Consolidate: Verbs Take turn, goes, play – retain play Mark vs. place vs. …? Use place symbol Remove implement – irrelevant to game Retain display, accumulate, exit and reset Remove “take turn” and “goes” as being close enough to “play.” Retain “play.” For now, retain “playing first” and the missing “playing second” as potentially refinements of “play.” The final design will show that they are not needed. Remove “mark” when used as a verb as being close enough to “place.” Retain “place,” but rename it “place symbol.” Remove “implement” as not being a responsibility relevant to the game, but rather to the process of building it. Retain “display,” “accumulate,” “exit,” and “reset” as valid responsibilities.

Candidate Classes, Responsibilities Classes: Symbol, Player, Human, Computer, Board, Row, and Game (with attribute Score) Instances: O, X of the class Symbol Responsibilities: play, place, display, accumulate (scores), quit, and reset.

Allocate Responsibilities to Classes Class Game is allocated the responsibilities: play, accumulateScores, quit, and reset. Class Board has Display responsibilities. Class GameGrid has Place. Symbol, Player, Human, Computer, and Row have no responsibilities yet. Keep?

Map Domain Model to Framework Patterns Controller classes map to Activities, e.g. GameSession Visual elements (if any, remember we’re doing domain object design) map to views Pure domain objects map to “plain old Java object” (POJO) hierarchies

General Scenario Start a new game. Determine who plays first: the human or the computer. Assign the X symbol to the first player; assign the O symbol to the second player. The first player places his symbol at an empty location on the board. The second player does likewise. Repeat until one player has three of his symbols in a row, column, or diagonal, or no more squares are in play, in which case the game ends in a draw. Accumulate scores for the players. The winning player’s score increments by 1; the losing player’s score does not change. In a draw, both players’ scores remain the same. If the user wishes, start a new game; else, quit.

Screens and Screen Flows in Tic-Tac-Toe

Scenario Walkthrough – Verification, Identifying Collaborators No class to respond to starting new game. Create one: GameController? GameController and Game collaborate Symbol creation, placement? Symbol and Board. placeSymbol invokes Play? Game needs checkResult? Board, GameGrid and Game are collaborators. Etc.

Final Classes, Responsibilities Game: Represents a single Tic-Tac-Toe game. Responsibilities: play, checkResult Collaborators: GameSession, GameView, Grid. GameView: Represents the visual display of a Tic-Tac-Toe game. Responsibilities: placeSymbol, showScores Collaborators: Game GameGrid: Represents 3×3 Tic-Tac-Toe grid. Responsibilities: placeSymbol, getEmptySquares GameSession: Represents Tic-Tac-Toe play session (multiple games) Responsibilities: playNewGame, quit, decidePlayers, accumulateScores Collaborators: Game, GameView Symbol – represents a Tic-Tac-Toe symbol (i.e., an X or an O) Responsibilities: None

Contracts Game: GameView: play(Grid, Symbol, x, y) returns Success, Failure checkResultAndSetState(Grid) returns nothing isActive() returns true or false isWon() returns true or false isDrawn() returns true or false GameView: placeSymbol(Symbol, X, Y) returns Success, Failure showScores(PlayerOneScore, PlayerTwoScore) returns nothing.

Questions and comments? Thank You Questions and comments?