Programming Paradigms Seminar 3
Upcoming SlideShare
Loading in...5
×
 

Programming Paradigms Seminar 3

on

  • 486 views

 

Statistics

Views

Total Views
486
Views on SlideShare
330
Embed Views
156

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 156

https://jujo00obo2o234ungd3t8qjfcjrs3o6k-a-sites-opensocial.googleusercontent.com 156

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • If a class depends on upon other classes, to help carry out it’s responsibilities, it will have collaborators written by side the responsibilityIf a card is part of a hierarchy, it may have superclass or subclasses.
  • If a class depends on upon other classes, to help carry out it’s responsibilities, it will have collaborators written by side the responsibilityIf a card is part of a hierarchy, it may have superclass or subclasses.
  • Discovering Candidate ClassesRead Requirements DocumentsUnderline nouns and noun phrasesAdd them to candidate class listBrainstorm to find other potential classesClarifying the ScopeSelecting Core ClassesArchitectural DesignIdentify hot spotsUse appropriate design patternsTake advantage of existing software frameworksEliminate Unnecessary ClassesRemove ghost classesCombine synonyms Distinguish attributes from classes
  • Does it handle everything--Is the ATM responsible for updating accounting records? or just recording and mediating the transaction activity?
  • Limits its scope to banking information capture -- Leaving the user interface, security and actual account update to other systems.
  • Pree definition: Specialization (=adaption) takes place at points of predefined refinement that we call hot spots (Pree,1995, 1996, 1997).Predefine refinement aka the framework of the domain.
  • Hotspot also enables the reuse of the overall system architecture and common code.The Abstract classes of the framework intertwine with hotspots highlighted in grey.
  • http://docs.google.com/viewer?a=v&q=cache:ihjN-VmNNaEJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.97.6069%26rep%3Drep1%26type%3Dpdf+hot+spots+driven+approach&hl=en&gl=sg&pid=bl&srcid=ADGEESgC8vV6UzFjxHOKDLqcxcnVf1w-lJnBU13X9N-fsIP1trelhEudmWNpYpGhrfo-CcSlxFokUONDuYqRfajy_KDGuWHJYrU7kBJlVHjSBgHzCNHspTZ5_-rrcBVVgeN_9rrkfESg&sig=AHIEtbSbl7ozvrNrZ8ZTj9GxfgzZoBXpXAhttp://docs.google.com/viewer?a=v&q=cache:L-Yyq-nbVakJ:citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.76.4910%26rep%3Drep1%26type%3Dpdf+Wolfgang+pree+Which+aspects+of+the+domain+differ+from+application+to+application%3F&hl=en&gl=sg&pid=bl&srcid=ADGEESgBvu4B0-28tpkoszuKNLtOEoPjFUX36Mqk3AGyln5jDpwqb4NCPFoDIPvcYiyMw247ms-dPWtzz6S3Cz8BsKdv3ThLRyfZ5xllYa5IUACILcS96Lu4FuqLqiEiMHn8tXmR3Xhq&sig=AHIEtbQqPZKDE0evqNqUfZNF2vmG519FRQ
  • After Hotspot has been identified…
  • A framework is a collection of classes--some abstract, some concrete--that captures the architecture and basic operation of an application system. Systems are created by extending the given classes to add the specialized behaviors.

Programming Paradigms Seminar 3 Programming Paradigms Seminar 3 Presentation Transcript

  • Seminar 3: Making Good Progress
    Programming Paradigms
    [The Paradigms - Group 2]
  • We will always use system analysis and design at the start of every software project.
  • No approaches were taught to derived
  • Knowing an good approach can build a robust system design.
  • Let us learn an approach to do system analysis and design 
  • What is Object-Oriented Analysis & Design?
    7
    Teacher
    Student
    An approach that models a system as a group of interacting objects.
  • New approach to analysis & design
    8
  • CRC Approach
    9
  • What is CRC?
    Class, Responsibility & Collaboration
    Discovering the real world objects is a system
    Mapping the collaboration among classes and their responsibilities
  • Why CRC?
    Uses brainstorming and role-playing to maximize advantages of group work
  • Basics of CRC approach
  • OO Characteristics
    13
  • The things they do
    Their relationship to other classes
  • Back of the card is used list attributes and write class description
    The things they do
    Their relationship to other classes
  • 16
  • QuickCRC 
    17
  • CRC books
    18
  • 19
  • CRC Card
    1. Discovering Candidate Classes
    1. Read Requirements Documents
    2. Clarifying the Scope
    2. Underline nouns and noun phrases.
    3. Selecting Core Classes
    3. Add them to candidate class list.
    4. Brainstorm to find other potential classes.
  • 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
    1. Read Requirements Documents
  • 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 numberusing the ATM.
    1. Discovering The Candidate Class List
    2. Underline nouns and noun phrases.
  • 23
    1. Discovering The Candidate Class List
    Candidate Class List
    3. Add them to 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
  • 1. Discovering The Candidate Class List
    4. Brainstorm to find other potential classes.
  • 25
    Q: How does the customer access the ATM?
    1. Discovering The Candidate Class List
    4. Brainstorm to find other potential classes.
  • 1.Discovering The Candidate Class List
    Candidate Class List
  • 27
    CRC Card
    1. Read Requirements Documents
    1. Discovering Candidate Classes
    2. Underline nouns and noun phrases.
    2. Clarifying the Scope
    3. Add them to candidate class list.
    3. Selecting Core Classes
    4. Brainstorm to find other potential classes.
  • Clarifying System Scope
    What is and what is not part of the system.
  • Clarifying System Scope
    29
    What is the scope of the ATM system?
    Questions
    Does it handle everything?
    banking application
    user interface
    interactions between them
    Does it..
    updates accounting records?
    records and mediates the transaction activity?
    Other Possible questions
  • Clarifying System Scope
  • 31
    Clarifying System Scope
    The sharper the system boundaries, the easier the evaluation of candidate class list.
  • 32
    CRC Card
    1. Read Requirements Documents
    1. Discovering Candidate Classes
    2. Underline nouns and noun phrases.
    2. Clarifying the Scope
    3. Add them to candidate class list.
    3. Selecting Core Classes
    4. Brainstorm to find other potential classes.
  • Sort Candidate Class List
  • Essential Classes for the application
    4. Selecting Core Classes
  • Class that we are NOT able to categorize without knowing the system boundaries and definition
    4. Selecting Core Classes
    To be Reviewed further for categorization
  • Classes that are outsidethe system scope
    Printer, ScreenSave, and Prompt.
    Related to the user interface subsystem But not to the core banking application
    4. Selecting Core Classes
  • 37
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • What are Hot Spots?
    A hot spot is a portion of the system that is likely to change from one system variant to another.
  • What are Hot Spots?
    Hot spots encapsulatethe variable aspects within components.
    • Changes will only be made to hot spots
    • Interfaces 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
  •  Identify Hot Spots
    Identify hot spot by answering:
    • Which aspects of the domain differ fromapplication to application?
    (Help to generate a List of hot spots)
    Let’s apply this question to our ATM domain ...
  • Identify Hot Spots
    Analysis of ATM
    Q: Which aspects of the domain differ fromapplication to application?
    • Withdrawal handling. Why?
    Future
  • Identify hot spots
    Withdrawal handling is a hot spot.
    Initially supports the dispensing of cash; future may require update of cash cards.
    The classes that touch this hot spot include Account, Withdrawal, FundsAvailable, and BankCard.
  • Benefits of Hot Spots
  • 44
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • 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”
  • 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
  • “System Interaction Pattern"
    AuthorizeSystemInteraction
  • Example
    AuthorizeSystemInteraction
    Encapsulate Communication between ATM and the bank existing security system
  • Example of Patterns that can be considered
    Clients
    Servers
    Transactions
    Interacting Systems
    Interacting Devices
    Etc…
  • Some Good Pattern Books
  • 51
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • 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.
  • 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
  • Example in ATM
    54
    There are many papers on ATM that has been successfully built
    These framework can also be standards that existing ATM follows
  • Part of a Framework
    55
  • 56
    In the event where there is no available framework
    Use design patterns to aid the design and analysis part of the application
  • 57
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • Remove ghost classes
    Classes that do not fit within the application
    Classes that are related entities but are outside the system.
  • Example
    Printer, and Keypad are relevant but outside the application.
  • 60
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • 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.
  • Similarity
    BankCustomerand AccountHolder are probably synonyms.
    Adopt one of them or create a new name.
  • Situation based
    Balance and FundsAvailablemay or may not be different in concepts
    Example:
    A policy of disallowing withdrawals for some period after deposit of a check.
  • Caution!
    Be careful when the same word actually refers to different things!
    New core classes may be needed.
  • 65
    3. Selecting Core Classes
    Eliminate Unnecessary Classes
    Architectural Design Issues
    1. Identify hot spots
    1. Remove ghost classes
    2. Use appropriate design patterns
    2. Combine synonyms 
    3. Take advantage of existing software frameworks
    3. Distinguish attributes from classes
  • 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
  • Example
    It does not have any operations
    Balance and FundsAvailable
    • Few meaningful operations
    • Closely associated with Account.
  • Example
    Cannot change state
    Consider a PIN. If a PIN is viewed as being immutable, then it probably should be an attribute of Account.
    BUT
    If a PIN can change state (valid, invalid, and suspended), it should be a class.
  • 69
    So what do we have so far?
  • Annotated Candidate Class List
    Critical Classes
    FinancialTransaction
    Account
    BalanceInquiry
    Withdrawal
    Deposit
    AuthorizeSystemInteraction
    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)
  • Annotated Candidate Class List
    Irrelevant Items
    Transfer
    Receipt
    ReceiptPrinter
    Keypad
    Screen
    CashDispenser
    ScreenMessage
    Display
    Deposit
    EnvelopeFailure
    TimeOut
    KeyTransaction
    LogPrinter
    ScreenSaver
    Prompt
    Numeric Key
    Key
  • Thank you!
    End of Presentation