programming paradigms seminar 3

71
Seminar 3: Making Good Progress Programming Paradigms [The Paradigms - Group 2]

Upload: neoxiuting

Post on 27-May-2015

589 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Programming Paradigms Seminar 3

Seminar 3: Making Good Progress

Programming Paradigms

[The Paradigms - Group 2]

Page 2: Programming Paradigms Seminar 3

We will always use system analysis and design at the start of every software project.

Analysis

Design

ImplementationTesting

Maintenance

Page 3: Programming Paradigms Seminar 3

Well-done analysis and design Reduce risk

Page 4: Programming Paradigms Seminar 3

No approaches were taught to derived

Their properties

Their responsibilities

Critical classes

Page 5: Programming Paradigms Seminar 3

Knowing an good approach can build a robust system design.

Page 6: Programming Paradigms Seminar 3

Let us learn an approach to do system analysis and design

Page 7: Programming Paradigms Seminar 3

7

What is Object-Oriented Analysis & Design?

An approach that models a system as a group of interacting objects.

Teacher Student

Page 8: Programming Paradigms Seminar 3

8

New approach to analysis & design

Page 9: Programming Paradigms Seminar 3

9

CRC Approach

Page 10: Programming Paradigms Seminar 3

What is CRC?

Class, Responsibility & Collaboration

1. Discovering the real world objects is a system

2. Mapping the collaboration among classes and their responsibilities

Page 11: Programming Paradigms Seminar 3

Why CRC?

Uses brainstorming and role-playing to maximize advantages of group work

Page 12: Programming Paradigms Seminar 3

Basics of CRC approach

OO Characteristics

Knowing CRC Card

Page 13: Programming Paradigms Seminar 3

13

OO CharacteristicsAbstraction“Eliminate the Irrelevant,

Amplify the Essential”

Encapsulation“Hiding the Unnecessary”

Inheritance“Modeling the Similarity”

Polymorphism“Same Function Different Behavior”

Page 14: Programming Paradigms Seminar 3

ClassName , SubclassesResponsibilities Collaboration

The things they do Their relationship to other classes

Page 15: Programming Paradigms Seminar 3

Back of the card is used list attributes and write class description

StudentdoHomework Teacher

The things they do Their relationship to other classes

Page 16: Programming Paradigms Seminar 3

16

Page 17: Programming Paradigms Seminar 3

17

QuickCRC

Page 18: Programming Paradigms Seminar 3

18

CRC books

Page 19: Programming Paradigms Seminar 3

19

6. Identifying Hierarchy

5. Assigning Collaborators

4. Assigning Responsibilities

3. Selecting Core Classes

2. Clarifying the Scope

1. Discovering Candidate Classes

CRC Card

Page 20: Programming Paradigms Seminar 3

1. Read Requirements Documents

2. Underline nouns and noun phrases.

3. Add them to candidate class list.

4. Brainstorm to find other potential classes.

CRC Card

3. Selecting Core Classes

2. Clarifying the Scope

1. Discovering Candidate Classes

Page 21: Programming Paradigms Seminar 3

The ATM System will interface with the customer through a display screen , numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.

Customer may make deposits, withdrawals and balance inquires using the ATM machine, but the update of accounts will be handled by an interface to the Accounts system.

Customers will be assigned a PIN and clearance level by the security system which will be verified prior to transactions.

We would allow customers to update routine information such as change of address or phone number using the ATM.

1. Read Requirements Documents1.Discovering The Candidate Class List

Page 22: Programming Paradigms Seminar 3

The ATM System will interface with the customer through a display screen , numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer.

Customer may make deposits, withdrawals and balance inquires using the ATM machine, but the update of accounts will be handled by an interface to the Accounts system.

Customers will be assigned a PIN and clearance level by the security system which will be verified prior to transactions.

We would allow customers to update routine information such as change of address or phone number using the ATM.

1. Discovering The Candidate Class List

2. Underline nouns and noun phrases.

Page 23: Programming Paradigms Seminar 3

23

3. Add them to candidate class list. 1. Discovering The Candidate Class List

• ATM System • Customer• Display screen • Numeric • Special input keys• Bankcard reader• Deposit slot• Receipt printer• Deposits

• Withdrawals• Balance inquires• Accounts• PIN • Clearance level• Security system • Transactions• Change of address • Phone number

Candidate Class List

Page 24: Programming Paradigms Seminar 3

4. Brainstorm to find other potential classes.

1. Discovering The Candidate Class List

Page 25: Programming Paradigms Seminar 3

25

Q: How does the customer access the ATM?

Bank Card

Bankcard reader

Numeric Key Pad

PIN

4. Brainstorm to find other potential classes.

1. Discovering The Candidate Class List

Page 26: Programming Paradigms Seminar 3

Candidate Class ListATM FinancialTransaction BankCardBankCustomer PIN AccountSavingsAccount CheckingAccount TransferWithdrawal Deposit BalanceInquiryReceipt ReceiptPrinter KeypadScreen CashDispenser ScreenMessageDisplay FundsAvailable DepositEnvelopeFailureBalance TimeOutKey TransactionLogKey AccountHolder PrinterScreenSaver Prompt NumericKey

1.Discovering The Candidate Class List

Page 27: Programming Paradigms Seminar 3

27

CRC Card

3. Selecting Core Classes

2. Clarifying the Scope

1. Discovering Candidate Classes

1. Read Requirements Documents

2. Underline nouns and noun phrases.

3. Add them to candidate class list.

4. Brainstorm to find other potential classes.

Page 28: Programming Paradigms Seminar 3

Clarifying System Scope

What is and what is not part of the system.

Page 29: Programming Paradigms Seminar 3

29

Clarifying System Scope

What is the scope of the ATM system?

QuestionsDoes it handle everything?•banking application•user interface•interactions between them

Does it.. • updates accounting

records?• records and mediates the

transaction activity?

Other Possible questions

Page 30: Programming Paradigms Seminar 3

Clarifying System Scope

ATM scope: Banking information capture

User interface & actual account update

Page 31: Programming Paradigms Seminar 3

31

Clarifying System Scope

The sharper the system boundaries, the easier the evaluation of candidate class list.

Page 32: Programming Paradigms Seminar 3

32

CRC Card

3. Selecting Core Classes

2. Clarifying the Scope

1. Discovering Candidate Classes

1. Read Requirements Documents

2. Underline nouns and noun phrases.

3. Add them to candidate class list.

4. Brainstorm to find other potential classes.

Page 33: Programming Paradigms Seminar 3

Critical Undecided Irrelevant

Sort Candidate Class List

Page 34: Programming Paradigms Seminar 3

Essential Classes for the application

BalanceInquiry

Withdrawal Deposit

Account

4. Selecting Core Classes

Critical Undecided Irrelevant

Page 35: Programming Paradigms Seminar 3

Class that we are NOT able to categorize without knowing the system boundaries and

definition

Critical Undecided Irrelevant

4. Selecting Core Classes

To be Reviewed further for categorization

Page 36: Programming Paradigms Seminar 3

Classes that are outside the system scope

Printer, ScreenSave, and Prompt. Related to the user interface subsystem But not to the core banking application

Critical Undecided Irrelevant

4. Selecting Core Classes

Page 37: Programming Paradigms Seminar 3

37

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 38: Programming Paradigms Seminar 3

What are Hot Spots?

A hot spot is a portion of the system that is likely to change from one system variant to another.

Page 39: Programming Paradigms Seminar 3

What are Hot Spots?

Hot spots encapsulate the variable aspects within components. Changes will only be made to hot spotsInterfaces and the relationships among

components will become less prone to changes.

Aid in designing components where changes is seldom necessary or constraint to a class

Page 40: Programming Paradigms Seminar 3

Identify Hot Spots

Identify hot spot by answering:• Which aspects of the domain differ fromapplication to application?

Let’s apply this question to our ATM domain ...

(Help to generate a List of hot spots)

Page 41: Programming Paradigms Seminar 3

Identify Hot SpotsAnalysis of ATMQ: Which aspects of the domain differ fromapplication to application?

Withdrawal handling. Why?

Future

Page 42: Programming Paradigms Seminar 3

Benefits of Hot Spots

Code Reuse

Architecture Reuse

Ease Changes

Page 43: Programming Paradigms Seminar 3

44

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 44: Programming Paradigms Seminar 3

Design Patterns

• A design pattern is a design structure that has been successfully used in a similar context

“No Point Reinventing the Wheel”“Reuse and Adapt existing”

Page 45: Programming Paradigms Seminar 3

Design Patterns

• Pioneers have laid out the foundations– There exist library of patterns

• Apply them to them to the CRC cards– Speed up analysis

Application of Design Patterns may result in new classes that are not found during brainstorming

Page 46: Programming Paradigms Seminar 3

“System Interaction Pattern"

AuthorizeSystemInteraction

Page 47: Programming Paradigms Seminar 3

Example

Encapsulate Communication between ATM and the bank existing security system

AuthorizeSystemInteraction

Page 48: Programming Paradigms Seminar 3

Example of Patterns that can be considered

• Clients• Servers• Transactions• Interacting Systems• Interacting Devices• Etc…

Page 49: Programming Paradigms Seminar 3

Some Good Pattern Books

Page 50: Programming Paradigms Seminar 3

51

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 51: Programming Paradigms Seminar 3

Framework

• A collection of classes that captures the architecture and basic operation of an application system.

• Systems are created by extending the given classes to add the specialized behaviors.

Page 52: Programming Paradigms Seminar 3

• Frameworks are "upside down libraries“.• System control resides in framework code

that calls "down" to user-supplied code.• A blue print for the implementation

Framework

Page 53: Programming Paradigms Seminar 3

54

Example in ATM

• There are many papers on ATM that has been successfully built

• These framework can also be standards that existing ATM follows

Page 54: Programming Paradigms Seminar 3

55

Part of a Framework

Page 55: Programming Paradigms Seminar 3

56

In the event where there is no available framework

Use design patterns to aid the design and analysis part of the application

Page 56: Programming Paradigms Seminar 3

57

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 57: Programming Paradigms Seminar 3

Remove ghost classes

• Classes that do not fit within the application

• Classes that are related entities but are outside the system.

Page 58: Programming Paradigms Seminar 3

Example

Printer, and Keypad are relevant but outside the application.

Page 59: Programming Paradigms Seminar 3

60

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 60: Programming Paradigms Seminar 3

Combine synonyms

• Use a common name for same items

• This situation may arise when different groups within an organization use different names to refer to the same thing.

Page 61: Programming Paradigms Seminar 3

Similarity

BankCustomer and AccountHolder are probably synonyms.

Adopt one of them or create a new name.

Page 62: Programming Paradigms Seminar 3

Situation based

• Balance and FundsAvailable may or may not be different in concepts

Example:• A policy of disallowing withdrawals for some

period after deposit of a check.

Page 63: Programming Paradigms Seminar 3

Caution!

Be careful when the same word actually refers to different things!

New core classes may be needed.

Page 64: Programming Paradigms Seminar 3

65

3. Selecting Core Classes

Architectural Design Issues Eliminate Unnecessary Classes

1. Identify hot spots

2. Use appropriate design patterns

3. Take advantage of existing software frameworks

1. Remove ghost classes

2. Combine synonyms

3. Distinguish attributes from classes

Page 65: Programming Paradigms Seminar 3

Distinguish attributes from classes

Some candidate classes may turn out to represent information only!

A candidate class may be an attribute if:– It does not have any operations– It does not change

Page 66: Programming Paradigms Seminar 3

Example

It does not have any operations

Balance and FundsAvailable - Few meaningful operations - Closely associated with Account.

Page 67: Programming Paradigms Seminar 3

Example

Cannot change stateConsider a PIN. If a PIN is viewed as being immutable, then it probably should be an attribute of Account.

BUTIf a PIN can change state (valid, invalid, and suspended), it should be a class.

Page 68: Programming Paradigms Seminar 3

69

So what do we have so far?

Page 69: Programming Paradigms Seminar 3

Annotated Candidate Class List

Critical Classes• FinancialTransaction• Account• BalanceInquiry• Withdrawal• Deposit• AuthorizeSystemInterac

tion• BankCard

Undecided Classes• BankCustomer

(ghost - integrated with AuthorizeSystemInteraction)

• PIN (attribute)• SavingsAccount (attribute of Account)• CheckingAccount (attribute of

Account)• ATM (ghost -> system name)• FundsAvailable (attribute)• Balance (attribute)• AccountHolder (synonym)

Page 70: Programming Paradigms Seminar 3

Annotated Candidate Class List

Irrelevant Items• Transfer • Receipt• ReceiptPrinter• Keypad• Screen• CashDispenser• ScreenMessage• Display• Deposit

• EnvelopeFailure• TimeOut• KeyTransaction• LogPrinter• ScreenSaver• Prompt• Numeric Key• Key

Page 71: Programming Paradigms Seminar 3

Thank you!

End of Presentation