Object-Oriented Technology
Download
1 / 218

OOM oo2001CRC Koich.. - PowerPoint PPT Presentation


  • 290 Views
  • Updated On :

Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona.edu Outline Introduction of OO Concepts Introduction of UML Using Nouns Example 1: Electronic Filing Program Exercise: Computer-Based Gas Station RDD Approach

Related searches for OOM oo2001CRC Koich..

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'OOM oo2001CRC Koich..' - Ava


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Object-Oriented TechnologyDr. Koichiro IsshikiComputer Information DepartmentCal Poly, [email protected]

Dr. Koichiro Isshiki


Outline l.jpg
Outline

  • Introduction of OO Concepts

  • Introduction of UML

  • Using Nouns

    • Example 1: Electronic Filing Program

    • Exercise: Computer-Based Gas Station

  • RDD Approach

    • Example 2: Electronic Checkbook

    • Example 3: Elevator Simulation System

    • Exercise: Coffee Machine Controller

Dr. Koichiro Isshiki


Introduction of oo concepts l.jpg

Introduction of OO Concepts

Dr. Koichiro Isshiki


Methodology l.jpg
Methodology

  • A process for the organized production of software using a collection of predefined techniques and notational conventions.

    Early Years

Problem Domain

Solution Domain

(Some Ad-hoc Model)

Dr. Koichiro Isshiki


Structured methodology l.jpg
Structured Methodology

Problem Domain

Solution Domain

data structure data structure

Function 1

Function 2

Function 3

Dr. Koichiro Isshiki


Oo methodology l.jpg
OO Methodology

Problem Domain

Solution Domain

MessageMessage

Obj 1

Obj 2

Obj 3

Dr. Koichiro Isshiki


Procedural vs oo l.jpg
Procedural vs. OO

  • Procedural Approach - a program is a collection of procedures and functions

    read_from_tape ();

    read_from_file ();

    write_to_tape ();

    write_to_file ();

  • Object-Oriented Approach - a program is a collection of cooperating objects

    For object tape, define operations read & write

    For object file, define operations read & write

Dr. Koichiro Isshiki


Encapsulation combine data and code l.jpg
Encapsulation - combine data and code

e.g. visit to procedural doctor

- go to library and get medical books

- go to doctor’s office

- Doc, here are the books and here are my symptoms

- tell me my diagnosis

e.g. visit to OO doctor

- go to doctor’s office

- Doc, here are my symptoms

- tell me my diagnosis

Dr. Koichiro Isshiki


Encapsulation 2 l.jpg
Encapsulation (2)

e.g. procedural bread making

- get baking pan, mixing bowl, mixer

- get flour, yeast, oil

- get cookbook

- follow directions: pour, mix, knead, raise, knead, raise, bake, time, remove

e.g. OO bread making

- get flour, yeast, oil

- pour into automatic bread maker

- turn on

Dr. Koichiro Isshiki


Traditional system development l.jpg
Traditional System Development

  • Problems:

    • Software Projects

      • Maintenance Cost Escalate

      • Project Deadlines Slide

      • Cost Estimate Difficult

    • Processing

      • Excessive Transformations

      • Decreased Productivity

Dr. Koichiro Isshiki


Oo system development l.jpg
OO System Development

  • Iterative rather than sequential

  • User-centered analysis process

  • Concepts of objects appear in analysis and is carried through design and implementation

  • Early & easy prototypes

Dr. Koichiro Isshiki


Object oriented analysis l.jpg
Object-Oriented Analysis

  • A problem domain

  • A stage in the development cycle in which a real-world problem is examined to understand its requirements without planning the implementation

  • The process of studying user needs to arrive at a definition of system or software requirements

  • OOA contains the following activities:

    • finding the objects

    • organizing the objects

    • describing how the objects interact

    • defining the operations of the objects

Dr. Koichiro Isshiki


Object oriented design l.jpg
Object-Oriented Design

  • A solution model

  • The creation of an abstraction of a software system that is consistent with the requirements specifications and provides a reasonable description for implementation.

  • A series of decisions on what is most cost-effective implementation

  • OOD contains the following activities:

    • building system architecture

    • providing full definition of classes & user interface

    • designing algorithms to implement class operations

Dr. Koichiro Isshiki


Ood guidelines l.jpg
OOD Guidelines

  • Coupling - the “strength” of interdependencies between discrete components in a system.

    • It’s something to be minimized; e.g. use encapsulation.

    • For an OO system, we are concerned with the coupling between classes and objects that are not part of a gen-spec or whole-part hierarchy; e.g., we look for ways to minimize the number of messages between objects, as well as the complexity and content of the messages.

Dr. Koichiro Isshiki


Ood guidelines 2 l.jpg
OOD Guidelines (2)

  • Cohesion - the “strength” of association of elements within a system component (i.e. the degree to which the responsibilities of a single component form a meaningful unit)

    • An entity, such as a class, an operation, or a module, is coherent if it is organized on a consistent plan and all its parts fit together toward a common goal.

    • It’s something to be maximized; e.g., a single method should not contain both policy and implementation.

Dr. Koichiro Isshiki


Ood guidelines 3 l.jpg
OOD Guidelines (3)

  • Reuse

    • Code reuse

      • cut, copy, and paste

      • subroutines and “includes”

      • binary links

    • Design reuse

      • code reuse typically occurs at the bottom levels of a system design hierarchy while design reuse results in whole “branches” of the tree being reused

    • Specification reuse

      • eliminate completely the effort involved in designing, coding, and testing an implementation of that specification

Dr. Koichiro Isshiki


Introduction of uml l.jpg

Introduction of UML

Dr. Koichiro Isshiki


Slide18 l.jpg
UML

  • Unified Modeling Language

    • It unifies the methods of Booch, Rumbaugh, and Jacobson

    • Model -- an abstraction of something for the purpose of understanding it before building it

      • architectural models to show customers

      • airplane models for wind-tunnel tests

Dr. Koichiro Isshiki


Uml 2 l.jpg
UML (2)

  • It is a modeling language, not a method

  • A method consists of both a modeling language and a process

  • The modeling language is the notation that methods use to express designs

  • The process is their advice on what steps to take in doing a design

Dr. Koichiro Isshiki


Uml 3 l.jpg
UML (3)

  • Different parts of UML:

    • Views - show different aspects of the system

    • Diagrams - graphs that describe the contents in a view

    • Model elements - represent common oo concepts such as classes, objects, messages, and relationships

    • General mechanisms - provide extra comments, information, or semantics about a model element

Dr. Koichiro Isshiki


Views l.jpg
Views

  • Use-case view: A view showing the functionality of the system as perceived by external actors.

  • Logical view: A view showing how the functionality is designed inside the system, in terms of the system’s static structure and dynamic behavior.

Dr. Koichiro Isshiki


Diagrams l.jpg
Diagrams

  • For static parts of a system

    • class diagram

    • object diagram

    • component diagram

    • deployment diagram

  • For dynamic parts of a system

    • use case diagram

    • sequence diagram

    • collaboration diagram

    • state diagram

    • activity diagram

Dr. Koichiro Isshiki


Static dynamic l.jpg
Static & Dynamic

  • All systems have a static structure and dynamic behavior.

  • Static view represents structural, data aspects of a system. It does not describe the time-dependent behavior of the system.

  • Dynamic modeling is to demonstrate how the objects interact dynamically at different times during the execution of the system, i.e. how the objects collaborate through communication and how the objects within the system change state during the system’s lifetime.

Dr. Koichiro Isshiki


Use case modeling l.jpg
Use Case Modeling

  • Originates from Ivar Jacobson’s methodology (OOSE)

  • Purposes for use cases:

    • To provide a complete specification, from the users’ point of view, of how the system will function

    • To provide a basis for performing system tests that verify the system

  • Defines actors and use cases

  • Users are classified as actors in the system. For each actor, specific use cases are played against the system. Collectively the use cases detail everything that the users can do with the system.

Dr. Koichiro Isshiki


Use case modeling 2 l.jpg
Use Case Modeling (2)

  • Actor - someone or something that interacts with the system (send or receive messages to and from the system); an actor can be a human being or another system

  • Finding actors - by answering a number of questions:

    Who will use the main functionality of the system?

    Who will need support from the system to do their daily tasks?

    Who will need to maintain, administrate, and keep the system working?

    Which hardware devices does the system need to handle?

    With which other systems does the system need to interact?

    Who or what has an interest in the results that the system produces?

Dr. Koichiro Isshiki


Use case modeling 3 l.jpg
Use Case Modeling (3)

  • Use Case - a set of sequences of actions a system performs that yield an observable result of value to a particular actor

    • is always initiated by an actor (The actor must directly or indirectly order the system to perform the use case)

    • provides value to an actor

    • is complete (not a function call; a use case is not complete until the end value is produced)

  • Finding use cases - for each of the actors identified, ask:

    Which functions does the actor require from the system?

    What does the actor need to do?

    What input/output does the system need? Where does this I/O come from or go to?

Dr. Koichiro Isshiki


Use case modeling 4 l.jpg
Use Case Modeling (4)

  • Example - recycling machine

    • Two actors: the Customer and the Operator. Brian is the operator of the machine, so he normally acts as the Operator actor. However, sometimes he deposits his own bottles and cans, and then he acts as a Customer.

    • Use cases:

      Customers deposit cans and/or bottles.

      Customers print receipts.

      Customers collect money.

      Operators collect cans and/or bottles.

      Operators replace receipt paper.

      …….

Dr. Koichiro Isshiki


Use case diagram l.jpg
Use Case Diagram

Recycling Machine

Deposit cans/bottles

customer

Collect cans/bottles

Print receipt

Collect money

operator

Dr. Koichiro Isshiki


Finding the objects l.jpg
Finding the Objects

  • Using nouns (see example 1)

  • Responsibility driven approach (see example 2,3)

  • Using the things to be modeled (e.g. identify individual or group things, such as persons, organizations, locations, logs, reports, forms, etc.)

  • Using decomposition

  • Using generalization

  • Reusing an application framework

Dr. Koichiro Isshiki


Using decomposition l.jpg
Using Decomposition

  • Patient -> Surgical patient, Referral patient

Patient

referralPatient

name:String ssn:Number

surgicalPatient

rphys setPhysician() physicianIs()

surgery setSurgery() surgeryIs()

init() nameIs() SSNis()

Dr. Koichiro Isshiki


Using generalization l.jpg
Using Generalization

  • Surgical patient, Referral patient -> Patient

referralPatient

name:String ssn:Number

surgicalPatient

rphys setPhysician() physicianIs()

surgery setSurgery() surgeryIs()

init() nameIs() SSNis()

Dr. Koichiro Isshiki


Reusing an application framework l.jpg
Reusing An Application Framework

  • The steps of this technique follow:

    • identify one or more relevant application frameworks in the same application domain

    • reuse both objects and classes from previously developed frameworks (note that some of the classes may need to be modified to be reused in your specific application)

Dr. Koichiro Isshiki


Using nouns l.jpg

Using Nouns

Dr. Koichiro Isshiki



The electronic filing system l.jpg
The Electronic Filing System

  • Problem Statement

    • An electronic filing program (EFP) can be used to store and retrieve text documents. Any document created by a word processor may be stored in the electronic filing system. Documents may be filed along with keywords, authors, and/or a document description or abstract describing the document. Documents filed in the system may also be removed or deleted.

Dr. Koichiro Isshiki


The efp 2 l.jpg
The EFP (2)

  • Problem Statement (cont’d)

    • Documents stored using the EFP are indexed to enable rapid retrieval. Users may retrieve or locate documents based on their content, description, author(s), or user-defined keywords. Therefore, the document description, authors, keywords, and/or the actual text document itself may be searched.

    • A user may specify search criteria, which results in a number of documents being found that meet the specified search criteria. The user may then continue to specify additional search criteria, successively narrowing down the search until the required documents are found. Documents found that meet the user’s search criteria may then be viewed or printed.

Dr. Koichiro Isshiki


The efp 3 l.jpg
The EFP (3)

  • Problem Statement (cont’d)

    • The user is provided with the capability of specifying any “junk” words, which if found in the content of the document will not be searched or indexed - for example, and, or, not, the, if. The user can also specify which alphanumeric characters in the text document will be indexed and searchable (the filing character set), thereby limiting the search and index to only portions of a document(s).

Dr. Koichiro Isshiki


Identifying object classes l.jpg
Identifying Object Classes

  • Grammatical Inspection - nouns/noun phrases represent candidate objects/classes

    • Potential Object Classes:

      abstract, alphanumeric character, author,

      content, description, document, document description,

      EFP, electronic filing system, filing character set, index,

      junk word, keyword, number of documents,

      portion of the documents, search, search criteria,

      system, text document, user, user-defined keyword,

      word processor

  • By general knowledge

    • line, word, page

Dr. Koichiro Isshiki


Identifying object classes 2 l.jpg
Identifying Object Classes (2)

  • Problem Statement

    • An electronic filing program (EFP) can be used to store and retrieve text documents. Any document created by a word processor may be stored in the electronic filing system. Documents may be filed along with keywords, authors, and/or a document description or abstract describing the document. Documents filed in the system may also be removed or deleted.

Dr. Koichiro Isshiki


Identifying object classes 3 l.jpg
Identifying Object Classes (3)

  • Problem Statement (cont’d)

    • Documents stored using the EFP are indexed to enable rapid retrieval. Users may retrieve or locate documents based on their content, description, author(s), or user-defined keywords. Therefore, the document description, authors, keywords, and/or the actual text document itself may be searched.

    • A user may specify search criteria, which results in a number of documents being found that meet the specified search criteria. The user may then continue to specify additional search criteria, successively narrowing down the search until the required documents are found. Documents found that meet the user’s search criteria may then be viewed or printed.

Dr. Koichiro Isshiki


Identifying object classes 4 l.jpg
Identifying Object Classes (4)

  • Problem Statement (cont’d)

    • The user is provided with the capability of specifying any “junk” words, which if found in the content of the document will not be searched or indexed - for example, and, or, not, the, if. The user can also specify which alphanumeric characters in the text document will be indexed and searchable (the filing character set), thereby limiting the search and index to only portions of a document(s).

Dr. Koichiro Isshiki


Discarding unnecessary incorrect classes l.jpg
Discarding Unnecessary & Incorrect Classes

  • Redundant Classes - keep the most descriptive object/class name for object classes that express the same information

  • Irrelevant Classes - classes that have little or nothing to do with the problem domain should be eliminated

  • Vague Classes - classes should be specific (should not have ill-defined boundaries or be too broad in scope)

Dr. Koichiro Isshiki


Discarding unnecessary incorrect classes 2 l.jpg
Discarding Unnecessary & Incorrect Classes (2)

  • Attributes - attributes are properties of object classes and not object classes themselves

  • Operations - a name describes an operation that is applied to objects should be discarded as a potential object class

  • Implementation Constructs - anything that has to do with how the problem is solved should not be a part of the analysis model

Dr. Koichiro Isshiki


Redundant classes l.jpg
Redundant Classes

  • Document and text document are redundant. Text document is retained because it is more descriptive. Content refers to the document itself and is redundant with text document.

  • Filing character set and alphanumeric characters are redundant. Filing character set is retained because it’s more descriptive and makes more sense in the application domain.

Dr. Koichiro Isshiki


Redundant classes 2 l.jpg
Redundant Classes (2)

  • Description, document description, and abstract are redundant. Abstract is retained because it is a document description and is a familiar term in business and academia.

  • User-defined keyword and keyword are redundant. All keywords, documents, and authors must be specified by the user in the EFP. Therefore, user-defined is not relevant and keyword will be retained.

Dr. Koichiro Isshiki


Irrelevant classes l.jpg
Irrelevant Classes

  • Word processor is irrelevant since the creation of a document is outside the scope of the EFP software.

  • Portion of the document and number of documents have nothing to do with the problem and will also be eliminated.

  • User also has little to do with the problem. All systems have users, and later on we will need to create a user interface.

Dr. Koichiro Isshiki


Vague classes l.jpg
Vague Classes

  • System is too broad in scope. The system is really the EFP, therefore system will be discarded as a potential object class.

  • EFP and electronic filing system are rather broad in scope. It is the application we are attempting to build, and not an object class in itself.

Dr. Koichiro Isshiki


Attributes l.jpg
Attributes

  • A search operation requires search criteria in order to perform the search, but beyond that search criteria does not affect the problem. So search criteria should be treated as an attribute of a search operation. Search criteria is discarded as a potential object class.

Dr. Koichiro Isshiki


Operations l.jpg
Operations

  • Search involves a sequence of actions to locate one or more documents satisfying some search criteria. Search is discarded as a potential object class.

Dr. Koichiro Isshiki


Implementation constructs l.jpg
Implementation Constructs

  • Filing character set is an implementation construct. The exact representation of the collection of filing characters is a design issue. Filing character set is renamed filing character.

Dr. Koichiro Isshiki


Candidate object classes l.jpg
Candidate Object Classes

  • abstract keyword

    author line

    filing character page

    index text document

    junk word word

Dr. Koichiro Isshiki


Data dictionary l.jpg
Data Dictionary

  • The data dictionary provides a place to collect information about an object class that is considered important and to clarify the meaning of the object class.

  • Abstract - Brief statement of the essential thoughts of the document. The abstract may consist of several sentences describing what the specific document is all about.

    Author - Name of the person who wrote or originated the document. More than one author may be associated with a document.

Dr. Koichiro Isshiki


Data dictionary 2 l.jpg
Data Dictionary (2)

Filing character - An alphanumeric character that is recognized by the EFP. Some applications in which electronic filing is used may require that only specific characters or numbers be indexed and retrievable. Only electronic filing characters are indexed and retrievable.

Index - Each document is indexed in some manner to enable rapid retrieval of data. The indexing technique is not specifed at this point in time.

Dr. Koichiro Isshiki


Data dictionary 3 l.jpg
Data Dictionary (3)

Junk word - A word that is common in the vocabulary of the language and is not of any value for retrieval purposes. Junk words are therefore not indexed. Examples of junk words are the following: and, the, or, if, is, are.

Keyword - A word that helps the user to uniquely identify a document. Multiple keywords may be associated with a document.

Dr. Koichiro Isshiki


Data dictionary 4 l.jpg
Data Dictionary (4)

Line - Text documents are made of up to lines of words. A document must have at least one line. Each line in a text document may contain zero or more words.

Page - A text document that is not an empty document is made up of one or more pages. Each page consists of one or more lines.

Dr. Koichiro Isshiki


Data dictionary 5 l.jpg
Data Dictionary (5)

Text document - Document possibly created by an editor, word processor, desktop publishing tool, etc. A text document is divided into pages. A document must have one ore more pages. A page may consist of multiple lines. Each line may consist of multiple words. A word consists of one or more letters.

Word - An alphabetic character or some meaningful combination of alphabetic characters that represents a unit of language.

Dr. Koichiro Isshiki


Adding associations between classes l.jpg
Adding AssociationsBetween Classes

  • Grammatical Inspection - verb/verb phrases represent potential associations between object classes

    • Explicit verb phrases

    • Implicit verb phrases

    • Knowledge of problem domain

      (Note that: Associations that do not come directly from the problem statement should be verified with the user and the problem domain expert.)

Dr. Koichiro Isshiki


Explicit verb phrases l.jpg
Explicit verb phrases

Documents filed in system Documents filed with abstract

Documents filed with author Documents filed with keyword

Documents removed/deleted from system

Documents is retrievable EFP indexes documents

EFP retrieves text documents EFP stores text documents

User prints documents

User specifies indexable/searchable characters

User specifies junk words User specifies search criteria

User views documents Word processor creates document

Dr. Koichiro Isshiki


Implicit verb phrases l.jpg
Implicit verb phrases

Document referenced by index

Documents created external to EFP

Documents must be text only

Documents retrievable by abstract

Documents retrievable by author

Documents retrievable by content

Documents retrievable by keyword

Search criteria has abstract

Search criteria has author

Search criteria has keyword

Search criteria has word

Dr. Koichiro Isshiki


Knowledge of problem domain l.jpg
Knowledge of problem domain

Abstract describes document

Documents contain pages

Keyword identifies document

Lines contain words

Pages contain lines

Text document identified by author

Words contain alphanumeric characters

Dr. Koichiro Isshiki


Discarding unnecessary incorrect associations l.jpg
Discarding Unnecessary & Incorrect Associations

  • Associations between eliminated classes - any association stated in terms of those eliminated classes must also be eliminated or restated in terms of some other class

  • Irrelevant or Implementation associations - any associations dealing with implementation constructs or outside the problem domain are eliminated

  • Actions - potential associations describing transient events are discarded; only those that describe a permanent relationship between object classes should be retained

Dr. Koichiro Isshiki


Associations between eliminated classes l.jpg
Associations Between Eliminated Classes

  • The EFP was eliminated as a potential object class, so we can eliminate EFP indexes documents, EFP retrieves text documents, EFP stores text documents, Documents created external to EFP.

  • User was eliminated, so we can eliminate User prints documents, User specifies indexable/searchable characters, User specifies junk words, User specifies search criteria, User views documents.

  • Any associations specifying document are changed to text document.

Dr. Koichiro Isshiki


Irrelevant or implementation associations l.jpg
Irrelevant or Implementation associations

  • Documents must be text only is eliminated because it is outside the domain of the problem. Documents are created by programs other than the EFP, such as editors, word processors. Documents that are not recognized as text will be rejected by the EFP.

Dr. Koichiro Isshiki


Actions l.jpg
Actions

  • Documents filed with abstract, Documents filed with author, Documents filed with keyword,Documents retrievable by abstract, Documents retrievable by author, Documents retrievable by keyword describe interactions between the user and the EFP and not permanent relationships. They are all eliminated.

Dr. Koichiro Isshiki


Candidate associations l.jpg
Candidate Associations

  • Abstract describes document

    Documents contain pages

    Document referenced by index

    Keyword identifies document

    Lines contain words

    Pages contain lines

    Text document identified by author

    Words contain alphanumeric characters

  • Note that a number of these associations actually represent aggregation.

Dr. Koichiro Isshiki


A new object class l.jpg
A New Object Class

  • Alphanumeric character was discovered while analyzing potential associations between object classes. It was discarded as a potential object class in favor of filing character. It now seems more relevant since word contains alphanumeric characters which may be nonfiling.

  • The discovery of new object classes means the discovery of new associations - Word contains alphanumeric character.

Dr. Koichiro Isshiki


Other missing associations l.jpg
Other Missing Associations

  • Other associations are further identified between object classes:

    abstract contains lines

    line contains junk words

    index references text document

Dr. Koichiro Isshiki


Initial efp class diagram l.jpg
Initial EFP Class Diagram

references

identifies

*

1..*

Author

Index

*

identifies

*

*

Text document

Keyword

describes

1..*

0..1

Page

Abstract

1..*

1..*

Line

Junk word

*

*

*

*

Word

*

*

*

*

filing char

Alphanumeric char

Dr. Koichiro Isshiki


Adding attributes l.jpg
Adding Attributes

  • Attributes are data values that are held by the objects in a class.

  • Look for nouns followed by possessive phrases (e.g., the length of the bridge, the width of the road, the voltage of the computer, the number of characters in the document) in the problem statement to identify attributes.

  • Attributes can also be found by drawing on your knowledge of the application domain and the real world.

Dr. Koichiro Isshiki


Potential attributes l.jpg
Potential Attributes

  • Based on knowledge of application domain:

    AttributeObject

    Author name Author

    Character Filing character

    Character Alphanumeric character

    Date created Text document

    Document description Abstract

    Document file name Text document

    Document size Text document

    Index file name Index

Dr. Koichiro Isshiki


Potential attributes 2 l.jpg
Potential Attributes (2)

  • (cont’d)

    AttributeObject

    Index size Index

    Keyword name Keyword

    Line number Line

    Number of characters Word

    Page number Page

    String Word

    Word Junk word

Dr. Koichiro Isshiki


Discarding unnecessary incorrect attributes l.jpg
Discarding Unnecessary & Incorrect Attributes

  • Objects - entities that have features of their own are objects, not attributes. Attributes are pure data values. (no objects disguising themselves as attributes in our attributes list)

  • Qualifiers - a qualifier is a special attribute that reduces the effective multiplicity of an association and increase the semantic accuracy. Any attributes that appear to be qualifiers should be restated as such.

Dr. Koichiro Isshiki


Discarding unnecessary incorrect attributes 2 l.jpg
Discarding Unnecessary & Incorrect Attributes (2)

  • Link Attributes - if an attribute depends on the presence of the link, then it is a link attribute and not an object attribute. Use association class for link attributes. (no link attributes masquerading as object attributes in our list)

  • Internal Values - attributes that describe the internal state of an object and are invisible outside the object should not be part of the object model during analysis. Postpone this level of detail until design.

Dr. Koichiro Isshiki


Qualifiers l.jpg
Qualifiers

  • Qualification improves semantic accuracy. For instance, it is more informative to be told that a directory and file name combine to identify a file, rather than be told that a directory has many files.

*

Directory

file

file name

*

*

Directory

file

Dr. Koichiro Isshiki


Qualifiers 2 l.jpg
Qualifiers (2)

  • Author name, keyword name, and index file name qualify the associations - author identifies text document, keyword identifies text document, and index references text document, respectively. Author name, keyword name, and index file name are changed to qualifiers.

Dr. Koichiro Isshiki


Link attributes l.jpg
Link Attributes

  • A link attribute is a property of the links in an association. For instance, access permission is an attribute of Accessible by since access permission is a joint property of File and User, and cannot be attached to either File or User alone without losing information.

Accessible by

*

*

User

File

access permission

/etc/termcap (read) John Doe /etc/tempcap (read-write) Mary Brown /usr/doe/.login (read-write) John Doe

Dr. Koichiro Isshiki


Link attributes 2 l.jpg
Link Attributes (2)

  • Another link attributes example:

Works-for

Person

Company

*

*

boss

0..1

name ssn address

name address

salary job title

*

worker

performance rating

Dr. Koichiro Isshiki


Internal values l.jpg
Internal Values

  • Size of the index object, size of the text document object, and number of characters in the word objectare attributes that describe the internal states of the objects. They are eliminated from our analysis model but are added to the data dictionary so that they may be incorporated later into our object design model.

Dr. Koichiro Isshiki


Candidate attributes l.jpg
Candidate Attributes

  • Candidate AttributeObject

    Character ASCII character

    Date created Text document

    Document description Abstract

    Document file name Text document

    Line number Line

    Page number Page

    String Word

    Word Junk word

Dr. Koichiro Isshiki


Use inheritance to share common structure l.jpg
Use Inheritance to Share Common Structure

  • Note that filing characters will most likely be alphanumeric characters. Therefore, a word should consist of filing and nonfiling characters. Both filing and nonfiling characters are ASCII characters.

  • However, showing filing character and nonfiling character as subclasses of ASCII character would be trivial inheritance. The filing character and nonfiling character subclasses would not have distinctive attributes, associations, or behavior. We choose the representation to show ASCII character as having attribute, character, which is of the type filing or nonfiling.

Dr. Koichiro Isshiki


Initial efp class diagram with attributes l.jpg
Initial EFP Class Diagram with Attributes

identifies

references

*

Text document

author name

Author

Index

index file name

identifies

document file name creation date

keyword name

Keyword

*

1..*

describes

Page

0..1

page number

Abstract

description

1..*

Junk word

Line

*

*

1..*

word

line number

*

*

*

Ascii character

1..*

Word

string

character:filing or nonfiling

Dr. Koichiro Isshiki


Summary of deliverables l.jpg
Summary of Deliverables

  • The deliverables for developing the object model are:

    • the problem statement

    • the initial data dictionary

    • the object model

Dr. Koichiro Isshiki


Identifying actors use cases l.jpg
Identifying Actors & Use Cases

  • The major actor in the context of the EFP is the user. No physical devices (other than the parts of the computer system itself) or other computer applications are involved. Our scenarios will therefore be based on interactions between the user and the EFP.

  • A set of use cases for the EFP:

    • filing a document

    • searching for, or finding, a document

    • viewing a document

    • deleting a document

    • printing a document

    • changing the filing character set

    • changing the junk words

Dr. Koichiro Isshiki


Use case diagram84 l.jpg
Use Case Diagram

Filing a doc

Finding a doc

Viewing a doc

Deleting a doc

Printing a doc

user

Changing filing char set

Changing junk word

Dr. Koichiro Isshiki


Filing a document l.jpg
Filing a Document

  • Scenario 1. Normal scenario for filing a document.

    • The user wishes to file a document.

    • The user specifies a directory and a document file.

    • The user enters an abstract of the document, keywords, and/or authors.

    • The user requests the document to be filed.

    • The document is filed.

  • A possible format for the filing a document use case is shown in the following two figures.

Dr. Koichiro Isshiki


Filing a document 2 l.jpg
Filing a Document (2)

File a Document

File Name

path

OK

Files

Directories

jim.wri susan.wri article.doc computer.rpt

windows borland (..) (a) (b) (c)

Cancel

Reference Information

Dr. Koichiro Isshiki


Filing a document 3 l.jpg
Filing a Document (3)

Document Reference Information

Document Abstract:

Keywords:

Authors:

Cancel

OK

Dr. Koichiro Isshiki


Filing a document 4 l.jpg
Filing a Document (4)

  • Scenario 2. Filing scenario with exceptions.

    • The user wishes to file a document.

    • The user specifies a directory.

    • The user requests the document to be filed.

    • The EFP displays an error message and asks the user to specify both a directory and file name for the document.

    • The user cancels the operation.

Dr. Koichiro Isshiki


Searching for a document l.jpg
Searching for a Document

  • Scenario 3. Normal scenario requiring a single search for a document.

    • The user wishes to search for a document(s) meeting some specific criteria.

    • The user enters an abstract query for an abstract search, a word or phrase for a content search, one or more keywords for a keyword search, and/or one or more authors for an author search.

    • The user requests the search to start.

    • The EFP returns the names of the documents satisfying the search criteria.

    • The user selects a document.

    • The user views a document satisfying the search criteria.

    • The user ends the request for a search operation.

Dr. Koichiro Isshiki


Searching for a document 2 l.jpg
Searching for a Document (2)

  • Scenario 4. Search scenario with exceptions.

    • The user wishes to search for a document(s) meeting some specific criteria.

    • The user requests the search to start.

    • A message box is displayed showing an error message and asking the user to enter abstract, content, keyword, and/or author information as a query.

    • The user ends the request for a search operation.

Dr. Koichiro Isshiki


Searching for a document 3 l.jpg
Searching for a Document (3)

  • Scenario 5. Normal scenario requiring multiple searches for a document.

    • The user wishes to search for a document(s) meeting some specific criteria.

    • The user enters one or more keywords for a keyword search.

    • The user requests the search to start.

    • The EFP returns the names of the documents satisfying the search criteria.

    • The user selects a document.

    • The user views a document satisfying the search criteria.

    • The user enters additional keywords to narrow down the search.

    • The user requests the search to start.

    • The EFP returns the names of the documents satisfying the search criteria.

    • The user selects a document.

    • The user views a document satisfying the search criteria.

    • The user ends the request for a search operation.

Dr. Koichiro Isshiki


Searching for a document 4 l.jpg
Searching for a Document (4)

Search for A Document(s)

Search Results

Content Query:

Document Name

View

(and)

Abstract Query:

jim.wri computer.doc

(and)

Keyword Query:

Print

(and)

Author Query:

Done

Search

Done

Dr. Koichiro Isshiki


Viewing a document l.jpg
Viewing a Document

  • Only documents that have been retrieved from a search may be viewed by the EFP. Scenario 3 shows an example of a normal scenario for viewing a document found from a search. Scenario 6 shows an example with exception.

  • Scenario 6. Viewing scenario with exceptions.

    • The user wishes to search for document(s) meeting some specific criteria.

    • The user enters a query.

    • The user requests the search to start.

    • The EFP returns the names of the documents satisfying the search criteria.

    • The user tries to view a document satisfying the search criteria.

    • An error message is displayed indicating that a document must first be selected.

    • The user ends the request for a search operation.

Dr. Koichiro Isshiki


Deleting a document l.jpg
Deleting a Document

  • Only documents that have been filed by the EFP may be deleted. The EFP deletes only the index for the document and not the document itself.

  • Scenario 7. Normal scenario for deleting a document.

    • The user wishes to delete a document.

    • The user specifies a document.

    • The user requests the document to be deleted.

    • The document index is deleted.

  • Scenario 8. Delete scenario with exceptions.

    • The user wishes to delete a document.

    • The user requests the document to be deleted.

    • An error message is displayed requesting the user to specify a document.

    • The user cancels the operation.

Dr. Koichiro Isshiki


Deleting a document 2 l.jpg
Deleting a Document (2)

Delete a Document

File Name

path

Files

Directories

jim.wri susan.wri article.doc computer.rpt

windows borland (..) (a) (b) (c)

OK

Cancel

Dr. Koichiro Isshiki


Printing a document l.jpg
Printing a Document

  • A user may only print a document that has been retrieved as part of a search. Scenarios 3 and 5 may be used to print a document by simply replacing “views” with “prints”.

Dr. Koichiro Isshiki


Changing the character set l.jpg
Changing the Character Set

  • As stated in the problem statement, “the user can specify which alphanumeric characters will be indexed and searchable, thereby limiting the search and index to only portions of a document(s)”.

  • Scenario 9. Normal scenario for changing the character set.

    • The user wishes to add a character to the filing character set.

    • The user specifies a character to include in the filing character set.

    • The user requests the character to be included.

    • The character is included in the character set.

  • Scenario 10. Character set scenario with exceptions.

    • The user wishes to add a character to the filing character set.

    • The user specifies a character to include in the filing character set.

    • The user cancels the operation.

Dr. Koichiro Isshiki


Changing the character set 2 l.jpg
Changing the Character Set (2)

Changing Filing Characters

Characters

Character:

c d $ @ A

OK

Discard

Include

Cancel

Dr. Koichiro Isshiki


Changing the junk words l.jpg
Changing the Junk Words

  • As stated in the problem statement, “the user can specify any junk words, which will not be searched or indexed - for example, and, or, not, the, if.”

  • Scenario 11. Normal scenario for changing junk words.

    • The user wishes to add a new junk word to the program’s set of junk words.

    • The user enters a junk word.

    • The user requests the word to be added.

    • The word is added to the junk word set.

  • Scenario 12. Junk word scenario with exceptions.

    • The user wishes to add a new junk word to the program’s set of junk words.

    • The user enters a junk word.

    • The user cancels the operation.

Dr. Koichiro Isshiki


Changing the junk words 2 l.jpg
Changing the Junk Words (2)

Changing Junk Words

Junk Words

Junk Word:

and the if or him then was

Add

Delete

OK

Cancel

Dr. Koichiro Isshiki


Preparing sequence diagrams l.jpg
Preparing Sequence Diagrams

  • Sequence diagrams describe how groups of objects interact and collaborate, emphasize the time order of messages

  • Sequence diagrams are constructed by:

    • identifying events (or messages) in scenarios

    • identifying the actor/object that sends an event

    • identifying the actor/object that receives an event

Dr. Koichiro Isshiki


Sequence diagram for filing a document l.jpg
Sequence Diagram for Filing a Document

An User

A User Interface

A Text Document

request file operation

specify directory & file name

enter abstract, keywords, and/or authors

request document to be filed

process filing request

document filed

document filed

Dr. Koichiro Isshiki


Sequence diagram for searching a document l.jpg
Sequence Diagram for Searching a Document

An User

A User Interface

A Text Document

request search operation

enter abstract, content, keyword, and/or author queries

request search to start

find document(s)

list of documents meeting search criteria

list of documents meeting search criteria

select a document

view a document

Note that this is also the sequence diagram for viewing (printing) a document

end request for search

Dr. Koichiro Isshiki


Sequence diagram for deleting a document l.jpg
Sequence Diagram for Deleting a Document

An User

A User Interface

A Text Document

request delete operation

specify directory & file name

request document index deletion

delete document index

document index deleted

document index deleted

Dr. Koichiro Isshiki


Sequence diagram for changing character set l.jpg
Sequence Diagram for Changing Character Set

An User

A User Interface

request filing character operation

specify filing character to include

character included in set

Dr. Koichiro Isshiki


Sequence diagram for adding junk words l.jpg
Sequence Diagram for Adding Junk Words

An User

A User Interface

request junk word operation

enter junk word

request junk word to be added

junk word is added

Dr. Koichiro Isshiki


State diagrams l.jpg
State Diagrams

  • State Diagram (SD) - a set of states and events and their relationships to describe the behavior of a system (usually one state diagram for each object class with nontrivial dynamic behavior).

  • An event is something that happens at some point in time, e.g. left-mouse-button is clicked.

  • The attribute values held by an object represent the state of the object, e.g. the state of a person is healthy or unhealthy.

  • Event has no duration; state occupies an interval of time.

Dr. Koichiro Isshiki


State diagrams 2 l.jpg
State Diagrams (2)

  • States and events are dual of one another (i.e. an event separates two states and a state separates two events).

  • State diagram for light switch:

Flip switch

off

on

Flip switch

Dr. Koichiro Isshiki


State diagrams 3 l.jpg
State Diagrams (3)

  • The state of the system is the product of the states of all the objects (not represented by a single state of a single object).

  • General form:

Event [guard]

/action

State 1

entry/action

do/activity

exit/action

State 2

entry/action

do/activity

exit/action

Dr. Koichiro Isshiki


User interface class state diagram l.jpg
User Interface Class State Diagram

Start

selection

User Interface

File Document

Delete Document

Search

Filing Character

Junk Word

Dr. Koichiro Isshiki


File document state diagram l.jpg
File Document State Diagram

File Document

Document Data Input

Path Input

do:request file name file name entered/record file name

cancel operation selected /cancel operation

do:request directory name directory name entered/record directory name

document reference information requested

Document Reference Information

File do:file document

do:request keywords keywords entered/record keywords

do:request authors authors entered/record authors

file document operation selected [directory+file name entered]

do:request abstract abstract entered/record abstract

Dr. Koichiro Isshiki


Delete document state diagram l.jpg
Delete Document State Diagram

Delete Document

Path Input

do:request file name file name entered/record file name

do:request directory name directory name entered/record directory name

delete operation selected [directory+file name entered]

cancel operation selected /cancel operation

Delete do:delete document

Dr. Koichiro Isshiki


Search state diagram l.jpg
Search State Diagram

Search

Query Input

do:request content query content query entered/record query

cancel operation selected /cancel operation

do:request keyword query keyword query entered/record query

do:request abstract query abstract query entered/record query

end search

start search [query entered]

do:request author query author query entered/record query

list of document names generated

Find Documents do:look for document

complete examining search results

Search Results Visible

view document

do:present document in window

do:request file name file name entered/record file name

viewing done

print document

do:request directory name directory name entered/record directory name

do:print text document

print done

Dr. Koichiro Isshiki


Junk word state diagram l.jpg
Junk Word State Diagram

Junk Word

do:request junk word junk word entered/record junk word

cancel operation selected /cancel operation

delete

junk word operation complete

do:remove junk word

add

do:include junk word

Dr. Koichiro Isshiki


Filing character state diagram l.jpg
Filing Character State Diagram

Filing Character

do:request filing character filing character entered/record filing character

cancel operation selected /cancel operation

delete

filing character operation complete

do:remove filing character

include

do:add filing character

Dr. Koichiro Isshiki


Updating the object model l.jpg
Updating the Object Model

  • A user interface is an application object. The application object does not need to be included in the initial object model, but should be added to the object model after making up the dynamic model.

Dr. Koichiro Isshiki


Slide117 l.jpg

Revision of EFP Object Model

User interface

file document, search for document, delete a document, add/delete junk word, include/discard filing character, view document, print document

references

identifies

*

Text document

*

author name

Author

Index

index file name

document file name creation date

identifies

keyword name

Keyword

*

1..*

describes

Page

0..1

page number

Abstract

description

1..*

*

*

Junk word

Line

1..*

word

line number

*

*

Ascii character

*

Word

1..*

string

character:filing or nonfiling

Dr. Koichiro Isshiki


Summary of deliverables118 l.jpg
Summary of Deliverables

  • The deliverables for developing the dynamic model are:

    • scenarios of typical interaction sequences

    • sequence diagrams for each scenario

    • state diagrams for those classes with important dynamic behavior

    • a revised object model (if necessary)

Dr. Koichiro Isshiki


Key operations l.jpg
Key Operations

  • File and find are the two major functions of the EFP system.

    • For the file operation, the processes include:

      • validate document type

      • create text document index

    • For the find operation, the processes include:

      • build search vector (for content query)

      • check for document matches (for content query)

      • check for document reference information matches (for abstract, keyword, author queries)

      • build document name list, i.e., the searching result

Dr. Koichiro Isshiki


Missing classes l.jpg
Missing Classes

  • Hash engine

    • Hash document record process has significant computation. We create a class, called hash engine, to collect all of the hashing functions together in one place.

      • This will minimize the impact on the system as these hashing algorithms are optimized.

    • Hash engine creates an index of a document.

Dr. Koichiro Isshiki


Missing classes 2 l.jpg
Missing Classes (2)

  • Search engine

    • The search engine class collects the search functions together in one place to facilitate a search.

    • The operations of search engine operate on the content query, search vector, filing directory, and document name list object classes.

  • Search vector

    • Build search vector is a top-level process that is implemented by several low-level processes.

    • A search vector is produced by a search engine.

Dr. Koichiro Isshiki


Missing classes 3 l.jpg
Missing Classes (3)

  • Content query

    • A content query is a collection of phrase(s) and query operator(s). It allows users to check for document matches. It has features of its own and is modeled as a class.

    • A content query will be processed by a search engine.

  • Document name list

    • Document name list class has an attribute that is a name list, generated as the result of a search.

    • Document name list is produced from search engine.

Dr. Koichiro Isshiki


Missing classes 4 l.jpg
Missing Classes (4)

  • Document reference information

    • Document reference information will be used to check for document reference information matches (in a find operation).

    • A document reference information class consists of zero or more author objects, zero or more keyword objects, and zero or more abstract. So it has an aggregate relationship with the author, keyword, and abstract objects.

Dr. Koichiro Isshiki


Adding operations to the om l.jpg
Adding Operations to the OM

  • OperationObject Class

    file document text document

    find document search engine

    create text document index document index

    build search vector search engine

    check for document matches content query

    check for doc ref info matches doc ref information

    hash document record hash engine

    build document name list search engine

Dr. Koichiro Isshiki


Adding operations to the om 2 l.jpg
Adding Operations to the OM (2)

  • OperationObject Class

    view document text document

    print text document text document

    delete document index filing directory

Dr. Koichiro Isshiki


Another missing classes l.jpg
Another Missing Classes

  • Filing directory

    • filing directory object class has zero or more index object classes

User interface

*

Filing directory

file document search for document delete a document add/delete junk word include/discard filing character view document print document

index file name

references

Index

*

index file name

Text document

Dr. Koichiro Isshiki


Slide127 l.jpg

Revision 2 of EFP Object Model

Document name list

0..1

*

Search engine

Filing directory

User Interface

1..*

build search vector build doc name list find doc

delete index

*

Operates on

Index file name

Index file name

Text document

yield

doc name dir name creation date

describes

Document reference information

0..1

utilizes

*

references

Index file name

1..*

0..1

Search vector

Index

file doc view doc print doc

check for document ref info matches

vector

create text doc index

build search vector

*

*

*

1..*

1..*

*

*

Page

1..*

Author

Keyword

Hash engine

0..1

Query

1..*

1..*

Abstract

hash doc record

Line

*

Word

*

String

1..*

ASCII char

1..*

Char:filing or nonfiling

Junk word

Nonjunk word

*

Dr. Koichiro Isshiki


Designing the application interface l.jpg
Designing the Application Interface

  • The steps in designing the interactive interface include:

    • Isolate user interface objects from the objects that define the semantics of the application.

    • Use the dynamic model as the structure of the program.

    • Fully specify the application functions invoked by the user interface.

Dr. Koichiro Isshiki


Menu bar pull down menus l.jpg
Menu Bar & Pull-Down Menus

File Document Storage Document Retrieval Utilities Help

Search...

Filing characters… Junk words...

Exit

File… Delete...

Contents Using Help Commands Dialog Boxes Junk Words Filing Characters

About Electronic Filing

Dr. Koichiro Isshiki


User interface class diagram l.jpg
User Interface Class Diagram

Window

exit file delete search filing characters junk words help

Dialog

*

File a Doc

Doc Ref Info

Search

Delete

Junk Word

OK cancel reference info

OK cancel

search cancel done

OK cancel

add delete OK cancel

Message Box

Filing Char

View

Search Results

Print

discard include OK cancel

view print done

OK cancel

Search Error, Delete Error, Invalid File, Invalid Filing Characters, Are You Sure, Filing in Progress

Dr. Koichiro Isshiki


Application objects domain objects relationships l.jpg
Application Objects & Domain Objects Relationships

File Dialog Box

Document Reference Information Dialog Box

Text Document

Document Reference Information

Print Dialog Box

View Window

Abstract, Keyword, and/or Author Query

Search Engine

Search Dialog Box

Search Results Dialog Box

Document Name List

Filing Directory

Delete Dialog Box

Junk Words Dialog Box

Junk Words

Filing Characters Dialog Box

Filing Characters

Dr. Koichiro Isshiki


Application objects domain objects relationships 2 l.jpg
Application Objects & Domain Objects Relationships (2)

  • User interface represents the user’s conceptual view of the system

    • The user should be involved in the design of the user interface (application objects).

  • Maintain a loosely coupled interface between the application objects and the domain objects

    • minimize the degree of change that the domain objects will have to undergo as the user interface changes

    • allow the domain objects to be reused with many different types of user interfaces

  • Dr. Koichiro Isshiki


    Map oo design into implementation l.jpg

    Map OO Design into Implementation

    Dr. Koichiro Isshiki


    Design association l.jpg
    Design Association

    • If the OOPL you use does not explicitly support association, then buried pointers are the easiest way to implement.

    • Example, two-way association:

    IsAssigned

    Person

    Car

    Dr. Koichiro Isshiki


    Design association 2 c l.jpg
    Design Association (2) – C++

    class Car;

    class Person { class Car {

    public: public:

    Person (Car *a=0); Car (char *a=0, int b=0, Person*c=0);

    IsAssigned(Car *); AssignPp (Person *p) {pp=p;}

    WhatCar(); char *WhatType() {return type;}

    protected: int WhatYear() {return year;}

    Car *pcar; protected:

    }; char *type;

    int year;

    Person *pp;

    };

    Dr. Koichiro Isshiki


    Design association 3 c l.jpg
    Design Association (3) – C++

    Void Person::IsAssigned (Car *car) {

    pcar = car;

    car->AssignPp(this);

    }

    void Person::WhatCar () {

    cout << pcar->WhatType() << endl

    << pcar->WhatYear() << endl;

    }

    Dr. Koichiro Isshiki


    Design association 4 c l.jpg
    Design Association (4) – C++

    • To ask a person “what’s the car assigned to you?”, just use the handle to get the information:

      Car newcar (“Honda”, 2000);

      Person John;

      John.IsAssigned (&newcar);

      …..

      John.WhatCar();

    Dr. Koichiro Isshiki


    Design association 5 java l.jpg
    Design Association (5) – Java

    class person {

    protected car pcar;

    public person() {pcar=null;}

    public person(car a) {pcar=a;}

    public void assignCar(car pc) {

    pcar = pc;

    pc.assignPerson(this); }

    public void whatCar() {

    System.out.println(“type is = “ + pcar.whatType());

    System.out.println(“year is = “ + pcar.whatYear()); }

    }

    Dr. Koichiro Isshiki


    Design association 6 java l.jpg
    Design Association (6) – Java

    class car {

    protected String type;

    protected int year;

    protected person pp;

    public car (String a, int b) {type=a; year=b; pp=null;}

    public car (String a, int b, person c) {type=a; year=b; pp=c;}

    public void assignPerson (person p) {pp=p;}

    public String whatType() {return type;}

    public int whatYear() {return year;}

    }

    Dr. Koichiro Isshiki


    Design association 7 java l.jpg
    Design Association (7) – Java

    class tryit {

    public static void main (String[] args) {

    car mycar = new car(“Honda”, 2000);

    person john = new person();

    john.assignCar(mycar);

    john.whatCar();

    }

    }

    Dr. Koichiro Isshiki



    Computer based gas station l.jpg
    Computer-Based Gas Station

    • Problem Statement

      • A computer-based system is required to control the dispensing of gasoline, to handle customer payment, and to monitor tank levels.

      • Before a customer can use the self-service pumps, the pump must be enabled by the attendant.When a pump is enabled, the pump motor is started, if it is not already on, with the pump clutch free.

    Dr. Koichiro Isshiki


    Gas station 2 l.jpg
    Gas Station (2)

    • When the trigger in the gun is depressed, closing a microswitch, the clutch is engaged and gasoline pumped. When it is released, the clutch is freed. There is also a microswitch on the holster in which the gun is kept that prevents gasoline being pumped until the gun is taken out. Once the gun is replaced in the holster, the delivery is deemed to be completed and the pump disabled. Further depressions of the trigger in the gun cannot dispense more gasoline. After a short standby period, the pump motor will be turned off unless the pump is reenabled.

    Dr. Koichiro Isshiki


    Gas station 3 l.jpg
    Gas Station (3)

    • A metering device in the gasoline line sends a pulse to the system for each 1/100 liter dispensed. Displays on the pump show the amount dispensed and the cost.

    • There are two kinds of pump. The normal kind allows the user to dispense gasoline as described above. The sophisticated pumps allow the customer to preset either an amount or a volume of gasoline. Gasoline will then be pumped up to a maximum of the required quantity.

    Dr. Koichiro Isshiki


    Gas station 4 l.jpg
    Gas Station (4)

    • Transactions are stored until the customer pays. Payment may be either in cash or by credit card. A customer may request a receipt and will get a token for every 5 dollars spent. Customers sometimes abscond without paying and the operator must annotate the transaction with any available information (e.g., the vehicle’s registration). At the end of the day, transactions are archived and may be used for inquiries on sales.

    Dr. Koichiro Isshiki


    Gas station 5 l.jpg
    Gas Station (5)

    • At present, two grades of gasoline are dispensed from five pumps on the forecourt. Each pump takes its supply from one of two tanks, one tank for each grade. The tank level must not drop below 4% of the tanks capacity. If this happens, the pumps serviced by that tank cannot be enabled to dispense gasoline

    Dr. Koichiro Isshiki


    Data dictionary147 l.jpg
    Data Dictionary

    • Attendant - employee of the fueling station who is authorized to enable pumps, handle all transactions on the computer (through a control console), and reorder gasoline when the tanks are low.

    • Clutch - part of the pump which opens/closes the valve which allows gasoline to flow through the nozzle (gun). When the clutch is engaged, the gasoline flows.

    Dr. Koichiro Isshiki


    Data dictionary 2148 l.jpg
    Data Dictionary (2)

    • Cost display - small display window on the pump which shows the running cost of the gas being pumped.

    • Credit card - method of payment whereby a customer presents his credit card number and expiration date and the funds are drawn from his credit line.

    • Display - electronic window which can create images of certain characters; numbers, letters, punctuation, etc.

    Dr. Koichiro Isshiki


    Data dictionary 3149 l.jpg
    Data Dictionary (3)

    • Gun - part of the pump through which gasoline is expelled when the clutch is engaged. The gun has a trigger which must be depressed to engage clutch. Gun is also referred to as a nozzle.

    • Holster - part of the pump which holds the gun when it is not in use. The holster has a microswitch which will not allow the clutch to be engaged unless the gun is lifted from the holster.

    • Motor - part of the pump which mechanically drives fuel from the tank to the nozzle when the clutch is engaged. The moter can either be on or off.

    Dr. Koichiro Isshiki


    Data dictionary 4150 l.jpg
    Data Dictionary (4)

    • Payment - the act of transferring funds from customer’s possession to fuel station’s possession.

    • Pump - mechanism which draws gasoline from a fuel tank and expels it through a nozzle when properly used. The pump consists of several important parts which each play a role in completing this task.

    • Sophisticated pump - a pump which prompts the user to enter a maximum quantity (by cost or by volume of gasoline) before allowing the user to dispense gasoline. Sophisticated pump is also referred to as a smart pump.

    Dr. Koichiro Isshiki


    Data dictionary 5151 l.jpg
    Data Dictionary (5)

    • Tank - a large storage vessel in which a particular grade of gasoline is held until it is pumped out. The tank will signal the attendant when its level has dropped to 4% or lower, and will not allow any pumps which draw from it to be enabled until the tank is refilled to more than 4% of its capacity.

    • Transaction - the act of a customer dispensing gasoline into his vehicle, then either paying for it or absconding. If the customer does not pay, then the attendant must annotate the transaction.

    Dr. Koichiro Isshiki


    Identifying object classes152 l.jpg
    Identifying Object Classes

    • Potential Object Classes

      • computer-based system, gasoline, customer payment, tank level, customer, self-service pump, pump, attendant, pump motor, pump clutch, trigger, gun, microswitch, clutch, holster, delivery, depressions, stand-by period, metering device, gasoline line, pulse, system, liter, display, amount, cost, normal kind, user, sophisticated pump, volume, maximum, quantity, transactions, cash, credit card, receipt, token, dollar, operator, information, vehicle, registration, inquiry, sales, grades, forecourt, supply, tank, capacity

    Dr. Koichiro Isshiki


    Identifying object classes 2153 l.jpg
    Identifying Object Classes (2)

    • Refinement Process

      • redundant: self-service pump

      • too broad: computer-based system, system

      • irrelevant: gasoline, customer, attendant, user

      • attribute: tank level

    • Candidate Object Classes

      • payment, pump, pump motor, gun, clutch, holster, display, sophisticated pump, transactions, cash, credit card, tank

    Dr. Koichiro Isshiki


    Identifying object classes 3154 l.jpg
    Identifying Object Classes (3)

    • Objects discovered by general knowledge

      • cost display, volume display

        • Problem statement states “Displays on the pump show the amount dispensed and the cost”.

      • preset key, preset display

        • “The sophisticated pumps allow the customer to preset either an amount or a volume of gasoline.”

      • daily transition record

        • “At the end of the day, transactions are archived and may be used for inquiries on sales.”

      • control console

    Dr. Koichiro Isshiki


    Identifying object classes 4155 l.jpg
    Identifying Object Classes (4)

    • Candidate Object Classes

      • Control Console, Tank, Pump,

        Motor, Cost Display, Volume Display,

        Clutch, Gun, Holster,

        SmartPump, Preset Key, Preset Display,

        Display, Transaction, Daily Transaction Record, Payment, Cash, Credit Card

    Dr. Koichiro Isshiki


    Associations l.jpg
    Associations

    • Verb Phrases:

      • Attendant enables pumps

      • Attendant annotates transactions

      • Cash is a type of payment

      • Credit card is a type of payment

    • Implicit Verb Phrases:

      • Pump consists of motor

      • Pump consists of clutch

      • Pump consists of gun

      • Pump consists of holster

    Dr. Koichiro Isshiki


    Associations 2 l.jpg
    Associations (2)

    • Implicit Verb Phrases: (contd.)

      • Pump consists of displays

      • Sophisticated pump is a type of pump

      • Sophisticated pump consists of a preset module

      • Preset module consists of a display

    • Knowledge of Problem Domain:

      • Transactions read from pump

      • Transaction consists of a payment

    Dr. Koichiro Isshiki


    Slide158 l.jpg

    Display

    Initial Object Model

    Smart Pump

    Preset Key

    Preset Display

    Tank

    capacity current level grade

    Cost Display

    Volume Display

    refill

    2

    2

    Motor

    5

    on?(y/n)

    Pump

    Clutch

    pump ID enabled?(y/n)

    5

    engaged?(y/n)

    enable

    Gun

    *

    Trigger depressed?(y/n)

    Transaction

    *

    Holster

    paid?(y/n) amount dispensed receipt requested?(y/n)

    gun in?(y/n)

    *

    Control Console

    annotate

    Daily Trans. Record

    Payment

    cost

    Credit Card

    Cash

    Dr. Koichiro Isshiki

    card number expiration date


    Dynamic model l.jpg
    Dynamic Model

    • Actors: Customer & Attendant

    • Use Cases for Customer:

      • Customer pump gasoline from a normal pump

      • Customer pump gasoline from a sophisticated pump

      • Customer pay to attendant

    • Use Cases for Attendant:

      • Attendant enable the pump

      • Attendant collect the payment

      • Attendant handle unpaid transactions

      • Attendant refill gas tanks

    Dr. Koichiro Isshiki


    Scenario 1 l.jpg
    Scenario 1

    • Scenario for “normal pump”

      • customer select pump #2 which is a normal pump

      • attendant enables the pump, the volume and cost counters return to zero and the pump motor starts

      • customer choose one grade of the gasoline

      • customer lift the gun from holster

      • customer press trigger, the clutch is engaged and start dispensing gasoline; the cost and volume counters start rolling while the gasoline is pumped

      • customer release trigger, the clutch is disengaged

      • customer replace the gun in the holster, the pump is disabled

    Dr. Koichiro Isshiki


    Scenario 2 l.jpg
    Scenario 2

    • “Normal pump” with exception

      • customer select pump #2 which is a normal pump

      • attendant enables the pump, the volume and cost counters return to zero and the pump motor starts

      • customer choose one grade of the gasoline

      • customer lift the gun from holster

      • customer put back the nozzle

      • pump operation canceled, the pump is disabled

    Dr. Koichiro Isshiki


    Interface for normal pump l.jpg
    Interface for Normal Pump

    total sale

    volume

    messages

    Octane 87

    Octane 92

    lift/put back nozzle

    press/release trigger

    Dr. Koichiro Isshiki


    Scenario 3 l.jpg
    Scenario 3

    • Scenario for “sophisticated pump”

      • customer select pump #3 which is a sophisticated pump

      • attendant enables the pump, the volume and cost counters return to zero and the pump motor starts

      • customer choose one grade of the gasoline

      • display on the pump show message asking customer to enter max volume or cost

      • customer input 10 gallons

      • customer lift the gun from holster

    Dr. Koichiro Isshiki


    Scenario 3164 l.jpg
    Scenario 3

    • Scenario for “sophisticated pump” (cont’d.)

      • customer press trigger, the clutch is engaged and start dispensing gasoline; the cost and volume counters start rolling while the gasoline is pumped

      • the pump motor slow down when there is one gallon of gasoline left to be pumped

      • 10 gallons of gasoline is pumped, the clutch is disengaged

      • customer release the trigger

      • customer replace the gun in the holster, the pump is disabled

    Dr. Koichiro Isshiki


    Interface for smart pump l.jpg
    Interface for Smart Pump

    messages

    preset amt or vol

    total sale

    volume

    1

    2

    3

    amt

    4

    5

    6

    Octane 87

    Octane 92

    7

    8

    9

    vol

    press/release trigger

    lift/put back nozzle

    clr

    0

    ent

    Dr. Koichiro Isshiki


    Scenario 4 l.jpg
    Scenario 4

    • Scenario for “customer pay to attendant”

      • customer wishes to pay after he complete pumping the gas

      • customer gives the attendant the pump number

      • attendant informs the customer of the total

      • customer pays the amount in cash or credit card

      • attendant gives the change and tokens to the customer, if any

      • customer gets receipt from attendant, if requested

    Dr. Koichiro Isshiki


    Scenario 5 l.jpg
    Scenario 5

    • Scenario for “attendant to enable a pump”

      • customer wishes to enable a pump

      • attendant asks the customer for the pump number

      • customer specifies the pump number

      • attendant asks the customer license plate number

      • customer gives the license plate number

      • attendant presses enable button on control console

      • the pump is enabled

    Dr. Koichiro Isshiki


    Scenario 6 l.jpg
    Scenario 6

    • “Enable a pump” with exception

      • customer wishes to enable a pump

      • attendant asks the customer for the pump number

      • customer specifies the pump number

      • attendant asks the customer license plate number

      • customer decides to leave

      • attendant cancels the request

    Dr. Koichiro Isshiki


    Scenario 7 l.jpg
    Scenario 7

    • Scenario for “Attendant handle unpaid transactions”

      • attendant wish to enable a pump

      • control console notify the attendant previous unpaid transaction (which has a license plate number associated with it)

      • attendant record the information of unpaid transaction

      • control console clear the entry for the pump

    Dr. Koichiro Isshiki


    Scenario 8 l.jpg
    Scenario 8

    • Scenario for “Refill gas tanks”

      • tank level on control console gets updated by signals sent from a metering device in the gasoline line

      • control console displays a warning message that the tank has insufficient gasoline (below 4% of capacity)

      • attendant requests to refill the corresponding tank

      • refill is complete

    Dr. Koichiro Isshiki


    Interface for attendant l.jpg
    Interface for Attendant

    Control Console

    Pump#1 enable ID# Gal: $0.00 ($ per gallon)

    pay

    Pump#2 enable ID# Gal: $0.00 ($ per gallon)

    pay

    Pump#3 enable ID# Gal: $0.00 ($ per gallon)

    pay

    Pump#4 enable ID# Gal: $0.00 ($ per gallon)

    pay

    Pump#5 enable ID# Gal: $0.00 ($ per gallon)

    pay

    customer debts list

    tokens earned

    tank#1 level

    print receipt

    tank#2 level

    print report

    Dr. Koichiro Isshiki


    State diagram l.jpg
    State Diagram

    Enable Pump

    Info. Input

    do:request for pump number

    customer decides to leave

    pump number specified

    do:request for customer’s license plate ID ID specified/attendant record ID

    enable pump [ID entered for specified pump]

    enable pump [existing ID found]

    clear action completed

    Black List

    do:record information for specified pump

    do:clear all entries for specified pump

    record completed

    Dr. Koichiro Isshiki


    Sd for normal pump l.jpg
    SD for Normal Pump

    Normal Pump

    [pump is enabled]

    do:request customer to remove nozzle

    do:request customer to pull trigger

    nozzle removed [gas grade selected]

    do:request customer to put back nozzle

    do:request to select grade of gas

    nozzle is put back

    trigger is released

    trigger is pressed

    Pump do:start pumping

    Dr. Koichiro Isshiki


    Sd for smart pump l.jpg
    SD for Smart Pump

    Smart Pump

    [pump is enabled]

    do:request to select grade of gas

    do:request customer to pull trigger

    do:request to select option (cost or volume)

    do:request customer to put back nozzle

    cost selected

    volume selected

    trigger is released or specified cost (or volume) is reached

    nozzle removed

    nozzle is put back

    do:request to enter cost

    do:request to enter volume

    trigger is pressed

    cost or volume specified [grade selected]

    Pump do:start pumping

    do:request customer to remove nozzle

    Dr. Koichiro Isshiki



    Example 2 electronic checkbook l.jpg

    Example 2: Electronic Checkbook

    Dr. Koichiro Isshiki


    Electronic checkbook l.jpg
    Electronic Checkbook

    • The electronic checkbook program is an application that supports a user’s checkbook activities. The checkbook is a list of entries, each of a particular type. Users can record entries, e.g., checks, ATM withdrawals and deposits, payday deposits, in the checkbook. The checkbook program will calculate and record the new balance. The system will generate checks that correspond to check entries on request. The checkbook application will also search for and display particular entries or generate reports of sets of entries based on entry number, payee, tax status, or amount.

    Dr. Koichiro Isshiki


    Electronic checkbook 2 l.jpg
    Electronic Checkbook (2)

    • For users who choose to receive their bank statements in disk form, the system will also balance their checkbook, automatically adding entries to the checkbook for transactions on the bank statement not accounted for in the checkbook.

    Dr. Koichiro Isshiki


    Responsibility driven design l.jpg
    Responsibility-Driven Design

    • Step 1. Actions or activities to be performed

      • Maintain checkbook entries, including add/edit/delete entries

      • Calculate and record new balance

      • Generate checks that correspond to check entries

      • Search for and display particular entries

      • Balance check book based on bank statements

    Dr. Koichiro Isshiki


    Rdd step 2 l.jpg
    RDD - Step 2

    • Step 2. Find the objects

      After defining the system by drawing lines and determining what is within and what is outside it, you can now ask what objects are required to model the system and accomplish these goals. You can identify those objects with a real-life counterpart in the application domain. You can use object abstraction, knowledge of the application domain, and the definition of class to intuitively identify objects and classes. This is the same way experienced developers would recognize functional and process abstractions. For instance, Checkbook, Bank Statement, Entry, and Check Entry are necessary objects in our electronic checkbook software.

    Dr. Koichiro Isshiki


    Rdd step 3 l.jpg
    RDD - Step 3

    • Step 3. Determine their responsibilities

      -- When you have made a first guess at listing the required objects, you can then ask what each individual object will do.

      -- Responsibilities include two key items: the knowledge an object maintains, and the actions an object can perform. The following is a list of responsibilities we identify for the above objects:

      • Checkbook: to maintain user’s checkbook entries and to balance the checkbook

      • Bank Statement: to provide balance and a list of cleared entries

      • Entry: to keep track of date, amount, and cleared status of an entry

      • Check Entry: to represent entries in the checkbook correspond to written checks

    Dr. Koichiro Isshiki


    Rdd step 4 l.jpg
    RDD - Step 4

    • Step 4. Determine collaborations

      With whom will each object collaborate in order to accomplish each of its responsibilities? What other objects in the system hold knowledge it needs, or know how to perform some operation it requires? The objects within a program must collaborate; otherwise, the program would consist of only one big object that does everything. For instance, Checkbook should collaborate with Bank Statement to balance the checkbook, and collaborate with Entry to add/delete/search entries. The following is a simple class diagram to show the communication between the four objects in the electronic checkbook.

    Dr. Koichiro Isshiki


    Rdd step 4183 l.jpg
    RDD - Step 4

    Checkbook

    *

    Bank Statement

    *

    Entry

    Check Entry

    Dr. Koichiro Isshiki


    Rdd step 5 l.jpg
    RDD - Step 5

    • Step 5. Walk through scenarios by using CRC cards to refine your class design

      There is no explicit flow of control in the above diagram. The ordering of the responsibilities and collaborations can only be seen in an explanation of how the model accomplishes the system activities. Scenarios are specific examples of the use of the system. Scenarios drive the development of an object-oriented model.

    • Note that “collaborators” in CRC are modeled as one-way communication from initiator class to the collaborator.

    Dr. Koichiro Isshiki


    Rdd step 5185 l.jpg
    RDD - Step 5

    • Example - scenario for the checkbook application “What happens when a checkbook balances itself?”

      • Checkbook sets its working balance to the balance it gets from the Bank Statement object (via know balance)

      • Checkbook asks the Bank Statement for each of its entries, using Bank Statement’s know entries responsibility.

      • Checkbook either clears its own matching entry or adds the entry (via add entry) to its list.

    Dr. Koichiro Isshiki


    Rdd step 5186 l.jpg
    RDD - Step 5

    • In the case of clearing an entry, Checkbook needs to collaborate with Entry, via know cleared status, to update its status to “cleared”.

    • Checkbook updates its working balance by collaborating with each entry that is not “cleared”. Each Entry knows how to adjust balance based on what type of Entry it is.

    • Checkbook compares its real balance (via know balance) to its working balance and complains it they are not the same.

    Dr. Koichiro Isshiki


    Rdd step 5187 l.jpg
    RDD - Step 5

    • Example:

      previous balance 100

      1 deposit 50 150

      2 withdraw 80 70

      3 deposit 200 270

      4 check 120 150

      working_balance = BankStatement.know_balance() //assume 70

      entries, Entry.cleared_status = BankStatement.know_cleared_entries()

    Dr. Koichiro Isshiki


    Rdd step 5188 l.jpg
    RDD - Step 5

    • Example:

      previous balance 100

      1 deposit 50 150 

      2 withdraw 80 70 

      3 deposit 200 270

      4 check 120 150

       uncleared entries, working_balance = Entry.adjust_balance(working_balance)

      At the end, working_balance is equal to 150, which is the same as the checkbook balance.

    Dr. Koichiro Isshiki


    Crc card checkbook l.jpg
    CRC card - Checkbook

    Checkbook

    Know balance

    Balance ()

    Add/delete entry ()

    Search for entry ()

    Bank Statement, Entry

    Entry

    Entry

    Dr. Koichiro Isshiki


    Crc card bank statement l.jpg
    CRC card - Bank Statement

    Bank Statement

    Know balance

    Know cleared entries

    Dr. Koichiro Isshiki


    Crc card entry l.jpg
    CRC card - Entry

    Entry

    Know date

    Know amount

    Know cleared status

    Update cleared status ()

    Adjust Balance ()

    Dr. Koichiro Isshiki


    Crc card check entry l.jpg
    CRC card - Check Entry

    Check Entry

    Print subsystem

    Know check number

    Know tax status

    Generate check ()

    Dr. Koichiro Isshiki



    Elevator simulation system l.jpg
    Elevator Simulation System

    • The LiftSim is a pictorial simulation software for a building's elevator system. The system composes of up to 10 floors and up to 5 elevators. The user can take part in the simulation by, with keyboard, requesting, on each floor, whether to go up or down like in the real world. The users inside any elevator will be able to select destination at any floor.

    Dr. Koichiro Isshiki


    Elevator simulation system 2 l.jpg
    Elevator Simulation System (2)

    • Every elevator will start up of stage idle at floor 0. In normal situation, when there is a request from any floor, the elevator which is idle or moving to that way will be automatically selected by the control unit at center. The nearest one will accept the request and move to that floor if it is idle or stop by that floor if it is moving. In case that more than one are tie, for example right at the beginning, the control unit will determine by random. All elevators will turn to idle state, if all pending requests are served.

    Dr. Koichiro Isshiki


    Design l.jpg
    Design

    • Basically main components in this simulation can be categorized as set of Elevators, set of Floors, User and Control Unit.

    • Elevator will have states at least current floor, moving status, list of destination floors. The elevator can perform functions such as telling the current level and direction, move up or down, set destination floor, being asked whether or not a specific floor is destination.

    Dr. Koichiro Isshiki


    Design 2 l.jpg
    Design (2)

    • Floor will have state of request whether to go up or down or no request at all. Floor can have behaviors such as being set by User to go up or down and then send that requests to the control unit, clear the request up or down when any Elevator comes.

    • User will accept input from keyboard, allowing real user to select up or down at each floor and pass that request to that Floor. User also allows real users to select destination floor(s) in each elevator and pass that request to that elevator. Ending simulation is also done by User.

    Dr. Koichiro Isshiki


    Design 3 l.jpg
    Design (3)

    • Control Unit will be the core component, receiving requests on each floor, determine which elevator to service that request and ask and control elevators to serve those requests.

    • There may be facilitator such as display unit which performs on screen display the simulation that can be modified when the running platform is changed.

    Dr. Koichiro Isshiki


    Cs 356 group members l.jpg
    CS 356 Group Members

    • The following software LiftSim was designed and implemented by the A-Team group (Mike Holtz, Paul Ramirez, Gino Le, Ron Rodrigo, and Man Lau) in Spring 2000.

    Dr. Koichiro Isshiki


    Liftsim action list l.jpg
    LiftSim Action List

    • LiftSim accepts and stores input of the number of floors and elevators.

    • LiftSim allows you to create new users with source and destination floors.

    • LiftSim accepts requests on floors to go up or down or both.

    • LiftSim accepts buttons pushed by simulated users inside the elevators.

    • LiftSim calculates which is the most efficient elevator to send and sends it to fulfill the job request.

    • Elevators move to appropriately selected destinations.

    • Appropriate floor lights and elevator control panel lights turn on and off at appropriate times.

    Dr. Koichiro Isshiki


    Crc cards l.jpg

    Creates the initial GUI

    Accepts input for number of floors and number of elevators

    Starts Display Object and passes the number of floors and elevators

    CRC Cards

    Form

    Display

    Dr. Koichiro Isshiki


    Crc cards 2 l.jpg

    Creates the Graphical User Interface

    Draws the floors

    Draws the elevators

    Draws the panel lights

    Displays light when button is pushed

    Moves the elevator graphically

    Start Control Object and passes the number of floors and elevators

    Listens to real user inputs

    User

    CRC Cards (2)

    Display

    Control

    Dr. Koichiro Isshiki


    Crc cards 3 l.jpg

    Knows number of floors and elevators

    Receives requests on each floor

    Determines which elevator to send for each request

    Sends appropriate elevator to serve requests

    Elevator

    CRC Cards (3)

    Control

    Elevator

    Dr. Koichiro Isshiki


    Crc cards 4 l.jpg

    Knows it’s current floor and moving status

    Adds a job (i.e. set destination floor)

    Keeps track of up and down requests

    Tells current level and direction

    Calculates distance an elevator must travel to reach a destination

    Moves up or down to a destination floor

    CRC Cards (4)

    Elevator

    Display, Floor

    Dr. Koichiro Isshiki


    Crc cards 5 l.jpg

    Knows its floor number

    Sends a request for an elevator

    Detects when an elevator arrives

    Keeps track of buttons pushed

    Control

    Display

    CRC Cards (5)

    Floor

    Dr. Koichiro Isshiki


    Crc cards 6 l.jpg

    Knows starting floor

    Knows destination floor

    Sends a request on starting floor

    Selects a destination floor

    CRC Cards (6)

    User

    Floor

    Elevator

    Dr. Koichiro Isshiki


    Liftsim class diagram l.jpg
    LiftSim Class Diagram

    *

    User

    *

    *

    create

    get in

    on

    serve

    *

    Elevator

    Floor

    *

    Display

    Form

    *

    *

    *

    *

    receive requests

    communicate

    Control

    Dr. Koichiro Isshiki



    Coffee machine interface l.jpg
    Coffee Machine Interface

    Coffee w/cream

    Coffee w/sugar

    Coffee w/both

    Coffee

    Coin insert slot

    Welcome …current total = 0

    Coin return slot

    Coffee drop box

    Cancel

    Dr. Koichiro Isshiki


    Coffee machine action list l.jpg
    Coffee Machine Action List

    • Collect, check, and accumulate coins

    • Return extra coins

    • Cancel operation

    • Keep track of inventory (coffee, cream, sugar, and cup)

    • Dispense items

    • Display messages

    Dr. Koichiro Isshiki


    Crc cards211 l.jpg

    Receive signals (insert coin, make selection, cancel)

    Collect money

    Display total

    Check enough money

    Check enough inventory

    Dispense coffee

    Display error messages

    Money Collector

    Money Collector

    Inventory Manager

    Item

    CRC Cards

    Interface Controller

    Dr. Koichiro Isshiki


    Crc cards 2212 l.jpg

    Know total

    Collect money (i.e. know current amount)

    Update total

    Enough money

    Return coins

    Item

    CRC Cards (2)

    Money Collector

    Dr. Koichiro Isshiki


    Crc cards 3213 l.jpg

    Know cost

    Know recipe

    Dispense itself

    Money Collector, Inventory Manager

    CRC Cards (3)

    Item //correspond to a button on the interface

    Dr. Koichiro Isshiki


    Crc cards 4214 l.jpg

    Know inventory

    Enough inventory

    Update inventory

    Item

    CRC Cards (4)

    Inventory Manager

    Dr. Koichiro Isshiki


    Coffee machine class diagram l.jpg
    Coffee Machine Class Diagram

    Interface Controller

    Inventory Manager

    Money Collector

    Item

    Dr. Koichiro Isshiki


    Oo design approaches l.jpg
    OO Design Approaches

    • OMT (Object Modeling Technique) [Rumbaugh et al.]

    • Booch [Booch]

    • OOSE (OO Software Engineering) [Jacobson et. al.]

    • CRC Cards [Beck & Cunningham]

    • RDD [Wirfs-Brock et. al.]

    • Coad/Yourdon [Coad & Yourdon]

    • Shlaer/Mellor [Shlaer & Mellor]

    • OOIE (OO Information Engineering) [Martin & Odell]

    • Fusion [Coleman et al.]

    • Unified Software Development Process [Rational Software Co.]

    Dr. Koichiro Isshiki


    Synthesis approach l.jpg
    Synthesis Approach

    • You may use any design process with the UML, UML is independent of process. UML is the notation to express design.

    Dr. Koichiro Isshiki


    References l.jpg
    References

    • Booch G, Rumbaugh J and Jacobson I, The Unified Modeling Language User Guide, Addison Wesley, 1999

    • Fowler M and Scott K, UML Distilled, 2nd ed., Addison Wesley, 2000

    • Derr Kurt, Applying OMT, SIGS Books, 1995

    • Wirfs-Brock R, Wilkerson B and Wiener L, Designing Object-Oriented Software, Prentice Hall, 1990

    • Wilkinson N, Using CRC Cards, SIGS Books, 1995

    • Lee R and Tepfenhart W, UML and C++, Prentice Hall, 1997

    • Budd T, An Introduction to Object-Oriented Programming, 2nd ed., Addison Wesley, 1997

    • Budd T, Understanding Object-Oriented Programming with JAVA, updated edition, Addison Wesley, 2000

    • Jacobson I, Booch G and Rumbaugh J, The Unified Software Development Process, Addison Wesley, 1999

    Dr. Koichiro Isshiki