slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona PowerPoint Presentation
Download Presentation
Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona

Loading in 2 Seconds...

play fullscreen
1 / 218

Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona - PowerPoint PPT Presentation


  • 295 Views
  • Uploaded 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

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

Object-Oriented Technology Dr. Koichiro Isshiki Computer Information Department Cal Poly, Pomona krisshiki @csupomona


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

Object-Oriented TechnologyDr. Koichiro IsshikiComputer Information DepartmentCal Poly, Pomonakrisshiki@csupomona.edu

Dr. Koichiro Isshiki

outline
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

Introduction of OO Concepts

Dr. Koichiro Isshiki

methodology
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
Structured Methodology

Problem Domain

Solution Domain

data structure data structure

Function 1

Function 2

Function 3

Dr. Koichiro Isshiki

oo methodology
OO Methodology

Problem Domain

Solution Domain

MessageMessage

Obj 1

Obj 2

Obj 3

Dr. Koichiro Isshiki

procedural vs oo
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
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
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
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
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
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
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
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
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
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

Introduction of UML

Dr. Koichiro Isshiki

slide18
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
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
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
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
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
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
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
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
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
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
Use Case Diagram

Recycling Machine

Deposit cans/bottles

customer

Collect cans/bottles

Print receipt

Collect money

operator

Dr. Koichiro Isshiki

finding the objects
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
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
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
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

Using Nouns

Dr. Koichiro Isshiki

the electronic filing system
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Candidate Object Classes
  • abstract keyword

author line

filing character page

index text document

junk word word

Dr. Koichiro Isshiki

data dictionary
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Filing a Document (3)

Document Reference Information

Document Abstract:

Keywords:

Authors:

Cancel

OK

Dr. Koichiro Isshiki

filing a document 4
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
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
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
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
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
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
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
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
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
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
Changing the Character Set (2)

Changing Filing Characters

Characters

Character:

c d $ @ A

OK

Discard

Include

Cancel

Dr. Koichiro Isshiki

changing the junk words
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

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
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
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
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
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
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
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
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
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
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

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
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
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
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
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
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

design association
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

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
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
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
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
Interface for Normal Pump

total sale

volume

messages

Octane 87

Octane 92

lift/put back nozzle

press/release trigger

Dr. Koichiro Isshiki

scenario 3
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
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
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
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
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
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
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
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
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
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
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
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

electronic checkbook
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
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
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
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
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
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
RDD - Step 4

Checkbook

*

Bank Statement

*

Entry

Check Entry

Dr. Koichiro Isshiki

rdd step 5
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
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
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
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
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
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
CRC card - Bank Statement

Bank Statement

Know balance

Know cleared entries

Dr. Koichiro Isshiki

crc card entry
CRC card - Entry

Entry

Know date

Know amount

Know cleared status

Update cleared status ()

Adjust Balance ()

Dr. Koichiro Isshiki

crc card check entry
CRC card - Check Entry

Check Entry

Print subsystem

Know check number

Know tax status

Generate check ()

Dr. Koichiro Isshiki

elevator simulation system
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
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
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
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
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
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
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
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
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
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
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
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
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
LiftSim Class Diagram

*

User

*

*

create

get in

on

serve

*

Elevator

Floor

*

Display

Form

*

*

*

*

receive requests

communicate

Control

Dr. Koichiro Isshiki

coffee machine interface
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
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
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
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
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
Know inventory

Enough inventory

Update inventory

Item

CRC Cards (4)

Inventory Manager

Dr. Koichiro Isshiki

coffee machine class diagram
Coffee Machine Class Diagram

Interface Controller

Inventory Manager

Money Collector

Item

Dr. Koichiro Isshiki

oo design approaches
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
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
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