Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa OBJECT DESIGN Now we need to design in such detail that.

Slides:



Advertisements
Similar presentations
Software Engineering 2003 Jyrki Nummenmaa 1 OO ANALYSIS & DESIGN FOR DATABASE-DRIVEN SOFTWARE Larger software products typically use a relational.
Advertisements

Use Case & Use Case Diagram
Chapter 8Java: an Introduction to Computer Science & Programming - Walter Savitch 1 Chapter 8 l Basic Exception Handling »the mechanics of exceptions l.
Software Engineering 2003 Jyrki Nummenmaa 1 OBJECT ARCHITECTURE DESIGN These slides continue with our example application, based on the simplified.
Chapter 7 – Object-Oriented Design
Software Engineering 2003 Jyrki Nummenmaa 1 OBJECT ANALYSIS Although there is some variance, most methods are based on what is called OMT (Object.
Information System Engineering
Recursion Chapter 7. Spring 2010CS 2252 Chapter Objectives To understand how to think recursively To learn how to trace a recursive method To learn how.
Chapter 2: Algorithm Discovery and Design
Fall 2007CS 2251 Recursion Chapter 7. Fall 2007CS 2252 Chapter Objectives To understand how to think recursively To learn how to trace a recursive method.
Recursion Chapter 7. Chapter 7: Recursion2 Chapter Objectives To understand how to think recursively To learn how to trace a recursive method To learn.
Recursion Chapter 7. Chapter 7: Recursion2 Chapter Objectives To understand how to think recursively To learn how to trace a recursive method To learn.
CHAPTER 10 Recursion. 2 Recursive Thinking Recursion is a programming technique in which a method can call itself to solve a problem A recursive definition.
Chapter 2: Algorithm Discovery and Design
Chapter 2: Algorithm Discovery and Design
Chapter 9 Domain Models 1CS6359 Fall 2012 John Cole.
Use case diagrams A use case diagram is UML’s notation for showing the relationships among a set of use cases and actors A use case diagram can help the.
Abstract Data Types (ADTs) Data Structures The Java Collections API
Chapter 9 Domain Models. Domain Model in UML Class Diagram Notation A “visual dictionary”
Language Evaluation Criteria
Classes and objects Practice 2. Basic terms  Classifier is an element of the model, which specifies some general features for a set of objects. Features.
M1G Introduction to Programming 2 4. Enhancing a class:Room.
1 Object-Oriented Testing CIS 375 Bruce R. Maxim UM-Dearborn.
5.1 and 5.4 through 5.6 Various Things. Terminology Identifiers: a name representing a variable, class name, method name, etc. Operand: a named memory.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa USE CASES In this lecture: Use cases - What are use.
TESTING.
Topic 3 The Stack ADT.
Chapter 3 Introduction to Collections – Stacks Modified
Chapter 2: Algorithm Discovery and Design Invitation to Computer Science, C++ Version, Third Edition.
Invitation to Computer Science, Java Version, Second Edition.
Recursion Chapter 7. Chapter Objectives  To understand how to think recursively  To learn how to trace a recursive method  To learn how to write recursive.
Putting together a complete system Chapter 10. Overview  Design a modest but complete system  A collection of objects work together to solve a problem.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa REQUIREMENT SPECIFICATION Today: Requirements Specification.
The Generic Gaming Engine Andrew Burke Advisor: Prof. Aaron Cass Abstract Games have long been a source of fascination. Their inherent complexity has challenged.
CSC 395 – Software Engineering Lecture 13: Object-Oriented Analysis –or– Let the Pain Begin (At Least I’m Honest!)
Arrays An array is a data structure that consists of an ordered collection of similar items (where “similar items” means items of the same type.) An array.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa OO A&D FOR DATABASE- DRIVEN SOFTWARE Larger software.
Software Engineering 2004 Jyrki Nummenmaa 1 A BASIC OO SOFTWARE DEVELOPMENT PROCESS Earlier, we saw a number of different software lifecycle models.
Comp 249 Programming Methodology Chapter 13 Interfaces & Inner Classes Dr. Aiman Hanna Department of Computer Science & Software Engineering Concordia.
Use Cases Use Cases are employed to describe the functionality or behavior of a system. Each use case describes a different capability that the system.
Designing Classes Chapter 3. 2 Chapter Contents Encapsulation Specifying Methods Java Interfaces Writing an Interface Implementing an Interface An Interface.
Use Case Diagram The purpose is to communicate the system’s functionality and behaviour to the customer or end user. Mainly used for capturing user requirements.
Design Model Lecture p6 T120B pavasario sem.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Computer Programming with JAVA Chapter 8. Exception Handling Basic Exception Handling the mechanics of exceptions Defining and Using Exceptions some "simple"
CSCI-383 Object-Oriented Programming & Design Lecture 10.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Design Patterns Software Engineering CS 561. Last Time Introduced design patterns Abstraction-Occurrence General Hierarchy Player-Role.
Object-Oriented Programming © 2013 Goodrich, Tamassia, Goldwasser1Object-Oriented Programming.
Application development with Java Lecture 21. Inheritance Subclasses Overriding Object class.
M1G Introduction to Programming 2 3. Creating Classes: Room and Item.
The Factory Method Pattern (Creational) ©SoftMoore ConsultingSlide 1.
8.1 8 Algorithms Foundations of Computer Science  Cengage Learning.
Object-Oriented Design Concepts University of Sunderland.
Introduction to Objects and Encapsulation Computer Science 4 Mr. Gerb Reference: Objective: Understand Encapsulation and abstract data types.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa OBJECT-ORIENTED ANALYSIS Earlier, we saw a number of.
Software Engineering 2003 Jyrki Nummenmaa 1 OBJECT DESIGN Now we need to design in such detail that the design can be implemented. It will be.
Program Design. Simple Program Design, Fourth Edition Chapter 1 2 Objectives In this chapter you will be able to: Describe the steps in the program development.
Recursion Topic 5.
Chapter 9 Domain Models.
GC211Data Structure Lecture2 Sara Alhajjam.
Use case diagrams A use case diagram is UML’s notation for showing the relationships among a set of use cases and actors A use case diagram can help the.
The Stack ADT. 3-2 Objectives Define a stack collection Use a stack to solve a problem Examine an array implementation of a stack.
The Metacircular Evaluator
Slides by Steve Armstrong LeTourneau University Longview, TX
OBJECT ARCHITECTURE DESIGN
6.001 SICP Interpretation Parts of an interpreter
CIS 375 Bruce R. Maxim UM-Dearborn
OBJECT DESIGN Now we need to design in such detail that the design can be implemented. It will be important to know, which structures the programming language.
Presentation transcript:

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa OBJECT DESIGN Now we need to design in such detail that the design can be implemented. It will be important to know, which structures the programming language supports, in order not to use inappropriate constructs. E.g. Java does not support multiple inheritance -> use interfaces instead in such situations.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Class Diagram Before Design isAtAirport(): Boolean hasMoney(): Boolean getPlace(): Place move(p: Place) isWinner(): Boolean hasTreasure(): Boolean giveTreasure(): Treasure takeTreasure(t: Treasure) pay() clearFunds() Player name: String funds: Integer move(p: Place) getPlace(): Paikka Piece color: Integer 0..1 Card effect (p: Pelaaja) value: Integer TreasureJewel Bandit own use 0..1 Players addPlayer(n: String) nextPlayer(): Player treasurePlayer(p: Place): Player initialize() addPlayer(n: String) throwDice() movePlayer(p: Paikka) takeCard(p: Place) end() Game play throw(): Integer Dice {ordered} * 1 1 FlightTraffic getDestinations(p: Place): set of Place hasCard():Boolean giveCard() Place located * SpecialPlace NormalPlace FlightRoute place * 2 Map giveAdjacent(p: Place, n: Integer): set 1 * cover * follow Aggregation Order of navigation

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa UserPlayer Choose to take card showFunds(p:Player) Examine All Sequence Diagrams! Game pay() Place Card turnCard() effect(p:Player) showFunds(p:Player)

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Object Design Tasks Improve efficiency by adding derived attributes and associations. Design implementation of associations. Increase maintainability by using design patterns. Reorganise class structure, inheritance and interfaces. Add additional classes, operations and attributes necessary for implementation. Design for user interface implementation. Edit the sequence diagrams to refer to existing classes. Identify operations based on the sequence diagrams. Describe complicated and important operations.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Finding operations Rewrite sequence diagrams to use existing classes Add parameters, if they are still missing. Collect operations.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Get Operations From Sequence Diagrams LuokkaOperationMeaning Playermove(p:Place)Move player to place p pay()Pay one unit game money hasMoney()True, if funds>0, false otherwise …

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Attribute types Class or a Primitive Type –E.g. Money or integer Class or several attributes –E.g. Point or two integers x,y

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Efficiency Considerations Shortening association paths –If necessary, add more associations. –Add an association between Game and Player Derived attributes –Avoid unnecessary re-computing –Explicit update, every time when source values change –Explicit update, at intervals –Implicit (compute when necessary)

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Association Design Study the associations and their usage –Usage in one or both directions? –If one, then which? –Are all associations necessary?

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Association Implementation Small cardinality (1 or 2, maybe 3) -> a referencing attribute Larger cardinality -> a container class, e.g. list Qualification -> a container class with hashing or indexing

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Nontrivial associations Aggregation associations –FlightTraffic-Flightroute –Map-Place Other –Place-Follow-Place –Players-Player

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Qualification and Indexing Qualification FlightTraffic getDestinations(p: Place): Set fee(p1, p2: Place): Integer giveCard() Place SpecialPlace cardSeen: Boolean hasCard():Boolean giveCard() NormalPlace Set placeNo ends {indexed} 1 * Place (or at least Special Place) must eventually have placeNo as an attribute. placeNo: Integer We are slowly iterating towards an implementable version. Only that version contains all details.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa FlightTraffic-FlightRoute Observations: –Qualification using Place –Association is used by getDestinations(p: Place), which returns a set of places based on a a given place. –FlightRoute objects are to be organised in such a way that for each place we can find the other places reachable with a flight route. Solution: –Each place is given an identifying number 0..n. Use a search structure (table, binary tree, …) to find other places based on the number. Similarly associations Map-Place and Place-Follow-Place

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa FlightTraffic-FlightRoute Search will be based on special places (as only they have flight connections. Therefore, we may give them numbers 0..k Create a table k x 1 table flightDestinations Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell flightDestinations[1] we find a list of possible flight destinations from place 1 (assuming k is at least 1).

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa FlightTraffic-FlightRoute: Table Only Search Structure As an alternative, create a boolean k x k table flightDestinations2 If there is a flight destination between special place i and special place j, then flightDestinations2[i,j]== flightDestinations2[j,i]==true else flightDestinations2[i,j]== flightDestinations2[j,i]==false Search is a bit slower, but implementation is easier.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Applying a similar idea to using dice Create a k x 6 table destinations (6 being the maximum value for dice) Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell [1,6] we find a list of possible destinations. Alternatively, use a k x 6 x k table: if you can walk from i to j with s steps, then destinations[i][s][j]==true

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa FlightTraffic-FlightRoute Search will be based on special places (as only they have flight connections. Therefore, we may give them numbers 0..k Create a k x 6 table (6 being the maximum value for dice) Each cell contains a list (or a reference to a list) of possible destinations, e.g. from cell [1,6] we find a list of possible destinations

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Players-Player Observations: –Navigation for finding the players –Operations nextPlayer() and treasurePlayer(p: Place) –Player objects need an order Solution: –Use a table indexed by player number. –Change {ordered} into {indexed}, qualification can be removed.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Abstract Classes and Virtual (Abstract) Operations Is it possible to define the operation for the superclass? -> If not -> {abstract}. If there are abstract operations, then the superclass will be abstract.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Superclass-Subclass Example Place is a superclass of SpecialPlace and NormalPlace. Operation hasCard is in a way only meaningful for special places. However, we may want to ask any place if it has a card. Solution: define hasCard for Place and make it return false by default. SpecialPlace will redefine hasCard.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Speculative Design Add abstract classes or interfaces E.g. prepare for new forms of transportation –New abstract class Traffic –with a virtual operation price (p1: Place, p2: Place): Integer. Same in FlightTraffic. –change operation fee() into form fee(h: Integer)

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Object Design Class Diagram

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Operation Design Operation descriptions are designed with such accuracy that it is possible to implement them based on this design. An operation form may be used.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Operation Form / 1 Class and operation declaration Description: A short operation description. Result: Result of the operation. Assumes: Preconditions, which are to be checked explicitly. Reads: Attributes, whose values the operation reads without modifying them, andobjects, whose state the operation reads without modifying them.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Operation Form / 2 Changes: Attributes, whose values are changed, and objects, whose instances are changed. Exceptions: Possible exceptions, under which the operation terminates abnormally and does not produce the required result. Scenario: Sequence diagram showing the related object interactions. Algorithm: Algorithm for the operation.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Operation Design Analysis-level description forms the basis. Examine operation uses in sequence diagrams. Preconditions guarantee that the operation can be executed (excluding exceptions).

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Operation Design Exceptions are described separately (execution terminates without correct result). If the object uses other objects during the execution, this can be described with a sequence diagram (it may be possible to get this from earlier diagrams). Non-trivial algorithms are written using a pseudo language.

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Example: treasurePlayer(p: Place) Class: Players Operation: treasurePlayer(p: Place): Player Description: If there is a player in place p with the treasure, returns that player. Result: Returns player Q, for which Q.owns  nil and Q.uses.located = p, if such Q exists, otherwise nil. Assumes: p  nil

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Example: treasurePlayer(p: Place) continued Reads: Player, Piece Exceptions: Player has no piece. Algorithm: while players not processed do Q = unprocessed player; if Q.hasTreasure() then if Q.getPlace() == p then return Q end end; return nil

Software Engineering – University of Tampere, CS DepartmentJyrki Nummenmaa Final Checks Check that everything matches: The required classes exist. The required operations exist. The required attributes exist. The required associations exist. The types match.