SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin...

59
SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City [email protected] [email protected] 850-522-2091 850-522-2023 Ex 182

Transcript of SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin...

Page 1: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

SEA Side Software Engineering

AnnotationsAnnotation 3: Analysis Patterns

Professor Sara StoecklinDirector of Software Engineering- Panama City

[email protected]

[email protected]

850-522-2091

850-522-2023 Ex 182

               

Page 2: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.
Page 3: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

I. WHAT

II. WHEN

III. HOW

IV. WHY

V. Example

Page 4: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Patterns: Webster :

Something regarded as a normative example to be copied.

Analysis: Phase of software development

Analysis Patterns:

Normative examples to be copied in the analysis phase of software development.

Page 5: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Analysis Patterns:

Normative examples to be copied in the analysis phase of software development.

Examples which are made into clusters of classes using polymorphic behavior to implement software.

Page 6: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Polymorphism: capability of assuming different forms

Polymorphic behavior: showing activity which can assume different forms.

Ex: write an add method which canadd integers, add reals, add colors

Page 7: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

  Examples: 1. Party2. Accountability3. Observation4. Inventory5. Accounting6. Trading7. Contracts8. Facades

Page 8: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 1. Party Pattern

Normative example to be copied in the analysis phase of software development.

During analysis of a registration system we determine that there are several types of students, types of professors, administrators, and types of departments and campus that need to be considered.

Each of these have some common characteristics. They have name, street address, city state, zip, some type of identification, date of birth, etc.

Page 9: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 1. Party Pattern

How many times will I need to validate zip code when someone enters it into a textfield. How many times will I need to validate SSN, code, month, day, year.

How many change name routines will I need to write

I would like to have a normative example of these repetitive items that can be identified during the analysis phase (an analysis pattern) and later during development have the capability of assuming different forms for each type of software (polymorphism).

Page 10: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

              

 

Knowledge level

1. Party Pattern

Therefore, I need to define a PARTY TYPE.This type defines the descriptive information (metadata) for a party and I will define classes of that type to implement the details.

Page 11: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

1

              

 

Knowledge level

Operational level

The knowledge level consists of party type. At the knowledge level the model records the general rules that govern the structure (Fowler, 1997).

The operational level is the implementation details.

1. Party Pattern

Page 12: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

Party 

1

0..M1

1

              

 

The operational level consists of party and the party subtypes. At the operational level the model records the day to day events of the domain.

Knowledge level

Operational level

Person 

Organization 

Post (appointments)

 

1. Party Pattern

Page 13: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

Party 

1

0..M1

1

              

 

Knowledge level

Operational level

Person 

Organization 

Post (appointments)

 

John Doe FSU Dean

Party Type ObjectRecord Min Max TableStudent Person StudentRecordUniversity Organization University UniversityT

1. Party Pattern

Page 14: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

Party 

1

0..M1

1

Knowledge level

Operational level

Person 

Organization 

Post (appointments)

 

1. Party Pattern – WHY DO I CARE?

REUSE, REUSE, REUSE – This concept allows me to reuse this party class in VARIOUS applications. It makes component building a reality. Pre-fab systems become marketable.

Page 15: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 2. Accountability Pattern

Normative example to be copied in the analysis phase of software development.

During analysis of a registration system we determine that there are several types of relationships between these parties.

Each of these relationships have some common characteristics.

Page 16: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 2. Accountability Pattern

Normative example to be copied in the analysis phase of software development.

Relationship ExamplesA student takes classes from a professor.A student takes classes from a department.A professor works in a department.A campus represents particular departments.

These are called ACCOUNTABILITIES.

Page 17: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 2. Accountability Pattern

How many times will I record the creation of these accountabilities. How many times will I need to look up information regarding particular accountabilities.

How many create relationship routines will I need to write

I would like to have a normative example of these repetitive items that can be identified during the analysis phase (an analysis pattern) and later during development have the capability of assuming different forms for each type of software (polymorphism).

Page 18: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

AccountabilityType

              

 

Knowledge level

2. Accountability Pattern

Therefore, I need to define a ACCOUNTABILITY TYPE.

This type defines the descriptive information (metadata) for a relationship between parties and I will define classes of that type to implement the details.

Page 19: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 

Knowledge level

Operational level

The knowledge level consists of the accountability type. At the knowledge level the model records the general rules that govern the structure (Fowler, 1997).

The operational level is the implementation details.

2. Accountability Pattern

AccountabilityType

Page 20: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

AccountabilityType

Accountability 

1

0..M1

1

              

 

Knowledge level

Operational level

Person is Dean of a Campus

Accountability Related Types ObjectRecord Actions Time PeriodManager of Person, department manages hires, fires begin end

Person, campus manages hires,fires begin endEnrolls in Person, class enrollment add,drop semesterAccepts in Person, campus accepts applies,… semester

Person, department accepts applies,… semester

2. Accountability Pattern

Person works for a Department

Page 21: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

2. Accountability Pattern – WHY DO I CARE?

REUSE, REUSE, REUSE – This concept allows me to reuse accountabilities (relationships) in VARIOUS applications. It makes component building a reality. Pre-fab systems become marketable.

AccountabilityType

Accountability 

1

0..M1

1

Knowledge level

Operational level

Page 22: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 3. Observation Pattern

Normative example to be copied in the analysis phase of software development.

During analysis of a registration system we determine that there are several types of observations we make about both the parties and the accountabilities (relationships).

Each of these observations have some common characteristics. They have a value of the observation, a category, and perhaps an assessment, demension, conversion rations.

Page 23: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 3. Observation Pattern

How many times will I need to validate an observation, to convert an observation, to record an observation.

How many enter observation routines will I need to write

I would like to have a normative example of these repetitive items that can be identified during the analysis phase (an analysis pattern) and later during development have the capability of assuming different forms for each type of software (polymorphism).

Page 24: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 

Knowledge level

3. Observation Pattern

Therefore, I need to define an observation type called a PHENOMENON TYPE and I need a PHENOMENON.

The type defines those type of observations needed and the phenomenon defines descriptive information (metadata) for an observation.

PhenomenonType

1

Phenomenon

1

0..M1

Page 25: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

Knowledge level

Operational level

EXAMPLES

PHENOMENON TYPE - DatePHENOMENON – Data of Birth, Date enrolled, date of death, ….

PHENOMENON TYPE - Test ScorePHENOMENON – GRE, Java Course, Drug, …..

3. Observation Pattern

PhenomenonType

1

Phenomenon

1

0..M1

Page 26: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

Knowledge level

Operational level

EXAMPLES

PHENOMENON TYPE - DatePHENOMENON – Data of Birth, Date enrolled, date of death, ….

PHENOMENON TYPE - Test ScorePHENOMENON – GRE, Java Course, Drug, …..

3. Observation Pattern

PhenomenonType

1

Phenomenon

1

Observation

0..M1

1

0..M

0..M1

Page 27: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

  3. Observation Pattern

Knowledge level

Operational level

PhenomenonType

1

Phenomenon

1

Observation

0..M1

1

0..M

Observation Type DataType Validator Min Max Table Label ErrorMessage

Show size Showsize Integer Range 4 20 Show Size Range is from 0 to 15

Hair color Haircolor String Discrete HairTable Hair Color Color Must be ……

Name Personname String Null Name

0..M1

Page 28: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

Party 

1

0..M1

1

Person 

Organization 

Post (appointments)

 

3. Observation Pattern – WHY DO I CARE?

REUSE, REUSE, REUSE – This concept allows me to reuse this party class in VARIOUS applications. It makes component building a reality. Pre-fab systems become marketable.

AccountabilityType

Accountability 

1

0..M1

1

PhenomenonType

1

Phenomenon

1

Observation

0..M1

1

0..M

Page 29: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

AccountType

PartyType

Account 

Party 

1

0..M

1

0..M

Knowledge Level

Operational Level

Time Period

0..M

1

has0..M 1..M

has0..M 1

              

The operational level consists of accounta, party, and their interrelationships. At the operational level the model records the day to day events. The knowledge level consists of account type, party type, and their relationships. At the knowledge level the model records the general rules that govern the structure (Fowler, 1997).

PostingRules

0..M 0..M

Entry 0..M 1..1

TransactionType

Transaction

11

Debit, Credit, Service Charge, Interest

0..M1..M

0..M1..M

Savings, Checking,

School, Inventory, GPA

Time Point

0..M

1

. MORE MORE MORE

Page 30: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

ContractType

PartyType

Contract 

Party 

1

0..M

1

0..M

Knowledge Level

Operational Level

Time Period

0..M

1

has0..M 1

              

InstrumentType

0..M 0..M

Instrument 0..M 1..1

Quote Type

Quote

11

Amount of Policy, Mortgage Balance, Mortage Interest,

Employment Offer, Value of Buy Option

1:.11..M

1:11..M

Marriage, Insurance, Real Estate, Employment, Stock Option, Loan

Time Point

0..M

1

License, Policy, Offer

Mortgage

Portfolio 

0..M

0..M

A quote is a value quoted about a particular instrument of a contract.A Portfolio is a collection of contracts that can be valued as a whole.

has 1..M

. MORE MORE MORE

Page 31: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

PartyType

Contract Selector  Party 

1

0..M

Knowledge Level

Operational Level

has0..M 1

              

InstrumentType

Instrument 0..M 1..1

1

Portfolio 0..M 0..M

A quote is a value quoted about a particular instrument of a contract.A Portfolio is a collection of contracts that can be valued as a whole.

ContractFilter

Hard CodedFilter

Set Filter

BooleanRoutine

SetOperation

Contract 

0:M

0..M

Portfolio Filter

1

0..M

0..M

1..1

. MORE MORE MORE

Page 32: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

AccountabilityType

PartyType

Accountability 

Party 

1

0..M

1

0..M

Knowledge Level

Operational Level

Time Period

0..M

1

commissioners

responsibles0..M

0..M 1..M

1..M

commissioner

responsible0..M

0..M 1

1

Constraint(s):X: self.Accountability .x.commissioner.type x.type.commissioners and x.responsible.type x.type.responsibles

              

 

The operational level consists of accountability, party, and their interrelationships. At the operational level the model records the day to day events of the domain. The knowledge level consists of accountability type, party type, and their relationships. At the knowledge level the model records the general rules that govern the structure (Fowler, 1997).

. MORE MORE MORE

Page 33: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 

ObservationType

Observation 

1

0..M

Knowledge level

Operational level

Validator Example

Page 34: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

  Validator Example

Scenario:

I write many different validation routines. I specify in my data dictionary about what constitutes a valid piece of data. Can’t I use the observation pattern to implement these various validation methods without writing each of them.

Page 35: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

              

 

DDManager

DataDictionaryRecord

1

0..M

Knowledge level

Validator Example

Observation Type DataType Validator Min Max Table Label ErrorMessage

Show size Showsize Integer Range 4 20 Show Size Range is from 0 to 15

Hair color Haircolor String Discrete HairTable Hair Color Color Must be ……

Name Personname String Null Name

DataDictionaryVectorM..1Observation

Type

Observation 

1

0..M

Operational level

Page 36: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator 

Range 

Discrete 

Null 

Validator Example

….

DDManager

DataDictionaryRecord

1

0..M

Knowledge level

DataDictionaryVectorM..1

Operational level

Page 37: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

TestFrame 

ObservationPanel 

observationLabel 

observationTextfield

Validator Example

observationErrorLabel 

ObservationType

Observation 

1

0..M

Knowledge level

Operational level

Page 38: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

DDManager DataDictionaryRecord

Validator Example

DataDictionaryVector

getMembercreate

addElememt

Page 39: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

TestFrame  ObservationPanel create

create

observationLabel 

observationTextfield

observationErrorLabel 

add

add

add

DataDictionaryVector

getMember(ddElementName):ddRecord

getvalue : textfieldvalueevent

We Know: ddElementName of the field value of the text field

Page 40: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

ObservationPanel 

observationLabel 

observationTextfield

observationErrorLabel 

DataDictionaryRecord Observation 

create

isValid(obsvalue)

ObservationType

create(ddElementName)

isValid(obsvalue)

We Know: ddElementName of the field value of the text field

Class 

creategetValidatorName forName

Range 

Discrete 

Null 

create

isValid(obsvalue)setText(message)

Page 41: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

DDManager DataDictionaryRecord

Validator Example

DataDictionaryVector

getMembercreate

addElememt

Page 42: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

TestFrame  ObservationPanel 

create

create

observationLabel 

observationTextfield

observationErrorLabel 

add

add

add

DataDictionaryVector

getMember (ddElementName): ddRecord

getvalue : textfieldvalueevent

We Know: ddElementName of the field value of the text field

Page 43: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public class ObservationPanel extends java.awt.Panel implements java.awt.event.ActionListener {

// items for the GUI interface

private java.awt.Label observationLabel = null;

private java.awt.Label errorLabel = null;

private String errorText;

private java.awt.TextField observationTextField = null;

// other variables

protected transient java.beans.PropertyChangeSupport propertyChange;

private String fieldDataDictionaryElementName = new String();// stores lookup name

private Observation dataElementObservation = null; // allows observation instance

private boolean observationValid = true; // temp variable

private String panelObservation; // String name of the observation

private String panelObservationText; // string name in observationpanel textfield

public ObservationPanel() { super(); initialize();}

public ObservationPanel(java.awt.LayoutManager layout) { super(layout);}

ObservationPanel 

Page 44: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example private void initConnections() { getObservationTextField().addActionListener(this);}

private void initialize() {

// sets up GUI

setName("ObservationPanel");

setLayout(null);

setSize(375, 88);

add(getObservationTextField(), getObservationTextField().getName());

add(getObservationLabel(), getObservationLabel().getName());

add(getErrorLabel(), getErrorLabel().getName());

initConnections();

// gets the meta Data about the GUI

DataDictionaryRecord ddrecord = DDManager.getMember(getDataDictionaryElementName());

getObservationLabel().setText( ddrecord.getLabelName() );

setErrorText( ddrecord.getInvalidObservationLabel() );

// The label size, textfield size, and panel size should adjusted from DD

setDataElementObservation( new Observation( getDataDictionaryElementName() ) );

}

Observation Type DataType Validator Min Max Table Label ErrorMessage

Show size Showsize Integer Range 4 20 Show Size Range is from 0 to 15

Hair color Haircolor String Discrete HairTable Hair Color Color Must be ……

Name Personname String Null Name

ObservationPanel 

Page 45: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public static void main(java.lang.String[] args) {

try { // try1

java.awt.Frame frame;

try { // try2

Class aFrameClass = Class.forName("com.ibm.uvm.abt.edit.TestFrame");

frame = (java.awt.Frame)aFrameClass.newInstance();

} // end try2

catch (java.lang.Throwable Exc) {frame = new java.awt.Frame(); }

ObservationPanel aObservationPanel;

aObservationPanel = new ObservationPanel();

frame.add("Center", aObservationPanel);

frame.setSize(aObservationPanel.getSize());

frame.setVisible(true);

} // end try1

catch (Throwable exception) {

System.err.println("Exception occurred in main() of java.awt.Panel");

exception.printStackTrace(System.out);

} // end catch

} // end main

ObservationPanel 

Page 46: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public synchronized void addPropertyChangeListener(java.beans.PropertyChangeListener listener) {

getPropertyChange().addPropertyChangeListener(listener);

} // end addPropertyChangeListener

// The firePropertyChange method was generated to support the propertyChange field.

public void firePropertyChange(String propertyName, Object oldValue, Object newValue) {

getPropertyChange().firePropertyChange(propertyName, oldValue, newValue);

} // end firePropertyChange

protected java.beans.PropertyChangeSupport getPropertyChange() {

if (propertyChange == null) {propertyChange = new java.beans.PropertyChangeSupport(this); };

return propertyChange;

} // end propertyChangefield

// The removePropertyChangeListener method was generated to support the propertyChange field.

public synchronized void removePropertyChangeListener(java.beans.PropertyChangeListener listener) {

getPropertyChange().removePropertyChangeListener(listener);

} // lend removePropertyChangeListner

public synchronized void addPropertyChangeListener(java.beans.PropertyChangeListener listener) {

getPropertyChange().addPropertyChangeListener(listener);

} // end addPropertyChangeListener

private void handleException(Throwable exception) {

/* Uncomment the following lines to print uncaught exceptions to stdout */

// System.out.println("--------- UNCAUGHT EXCEPTION ---------");

exception.printStackTrace(System.out);

} // end handleException

ObservationPanel 

Page 47: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public String getDataDictionaryElementName() {return fieldDataDictionaryElementName;}

public void setDataDictionaryElementName(String dataDictionaryElementName) {

String oldValue = fieldDataDictionaryElementName;

fieldDataDictionaryElementName = dataDictionaryElementName;

firePropertyChange("dataDictionaryElementName", oldValue, dataDictionaryElementName);

} // end setDataDictionaryElementName

public Observation getDataElementObservation() { return dataElementObservation;}

public void setDataElementObservation(Observation newValue) {

this.dataElementObservation = newValue;

} // end setDagtaElementObservation

public synchronized void addPropertyChangeListener(java.beans.PropertyChangeListener listener) {

getPropertyChange().addPropertyChangeListener(listener);

} // end addPropertyChangeListener

// The firePropertyChange method was generated to support the propertyChange field.

public void firePropertyChange(String propertyName, Object oldValue, Object newValue) {

getPropertyChange().firePropertyChange(propertyName, oldValue, newValue);

} // end firePropertyChange

ObservationPanel 

Page 48: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example private java.awt.Label getObservationLabel() {

if (observationLabel == null) {

try {

observationLabel = new java.awt.Label();

observationLabel.setName("ObservationLabel");

observationLabel.setText(" ");

observationLabel.setBackground(java.awt.Color.cyan);

observationLabel.setBounds(36, 29, 66, 23);

} // end try

catch (java.lang.Throwable Exc) { handleException(Exc); }

}; // end if

return observationLabel;

} // end getObservationLabel

//Return the TextField1 property value. @return java.awt.TextField

private java.awt.TextField getObservationTextField() {

if (observationTextField == null) {

try {

observationTextField = new java.awt.TextField();

observationTextField.setName("ObservationTextField");

observationTextField.setBounds(108, 29, 188, 23);

} // end try

catch (java.lang.Throwable Exc) { handleException(Exc); }

}; // end if

return observationTextField;

} // end getObservationTextfield

public String getPanelObservationText() { return panelObservationText;}

public void setDataElementObservation(Observation newValue) {this.dataElementObservation = newValue; }

ObservationPanel 

Page 49: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

private java.awt.Label getErrorLabel() {

if (errorLabel == null) {

try {

errorLabel = new java.awt.Label();

errorLabel.setName("ErrorLabel");

errorLabel.setText("");

errorLabel.setBounds(45, 61, 269, 23);

} // end try

catch (java.lang.Throwable Exc) { handleException(Exc); }

}; // end if

return errorLabel;

} // end ErrorLabel

public String getErrorText() { return errorText;}

ObservationPanel 

Page 50: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public void actionPerformed(java.awt.event.ActionEvent e) {

if ((e.getSource() == getObservationTextField()) ) { validateField(e); }

}// end actionPerformed

private void validateField(java.awt.event.ActionEvent arg1) {

try { this.validateObservation(); }

catch (java.lang.Throwable Exc) { handleException(Exc); }

} // end validateField

public boolean getObservationValid() { return observationValid;}

public void setErrorText(String newValue) {this.errorText = newValue;}

public void setObservationValid(boolean newValue) { this.observationValid = newValue;}

public void setPanelObservationText(String newValue) { this.panelObservationText = newValue;}

public void validateObservation() {

/* Perform the validateObservation method. */

getErrorLabel().setText("");

setObservationValid(true);

setPanelObservationText( getObservationTextField().getText() );

setObservationValid(getDataElementObservation().isValid(getPanelObservationText()));

if( !getObservationValid() ) {getErrorLabel().setText(getErrorText()); } // end if

else getErrorLabel().setText("Good Job");

} // end validateObservation

ObservationPanel 

Page 51: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

ObservationPanel 

observationLabel 

observationTextfield

observationErrorLabel 

DataDictionaryRecord Observation 

create

isValid(obsvalue)

ObservationType

create(ddElementName)

isValid(obsvalue)

We Know: ddElementName of the field value of the text field

Class 

creategetValidatorName forName

Range 

Discrete 

Null 

create

isValid(obsvalue)setText(message)

Page 52: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public class Observation {

private java.util.Date recordedDate;

private java.util.Date observedDate;

private int duration;

private ObservationType type;

private String observationTypeName;

public Observation() { super();}

public Observation(String ddElementName ) {

setType ( new ObservationType( ddElementName ) );

} // end constructor

public void createNewObservationType(String observationTypeName) {

this.observationTypeName = observationTypeName;

// here we create an instance of the primitive observation

// a factory pattern would create the instances of whatever type you need

setType(new PrimitiveObservationType());

} // end createNewObservationType

Observation 

Page 53: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

public int getDuration() { return duration;}

public String getObservationTypeName() { return observationTypeName;}

public java.util.Date getObservedDate() { return observedDate;}

public java.util.Date getRecordedDate() { return recordedDate;}

public ObservationType getType() { return type;}

public boolean isValid (String obsValue) { return getType().isValid( obsValue );}

public void setDuration(int newValue) { this.duration = newValue;}

public void setObservationTypeName(String newValue) { this.observationTypeName = newValue;}

public void setObservedDate(java.util.Date newValue) { this.observedDate = newValue;}

public void setRecordedDate(java.util.Date newValue) {this.recordedDate = newValue;}

public void setType(ObservationType newValue) { this.type = newValue;}

} // end class

Observation 

Page 54: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

ObservationPanel 

observationLabel 

observationTextfield

observationErrorLabel 

DataDictionaryRecord Observation 

create

isValid(obsvalue)

ObservationType

create(ddElementName)

isValid(obsvalue)

We Know: ddElementName of the field value of the text field

Class 

creategetValidatorName forName

Range 

Discrete 

Null 

create

isValid(obsvalue)setText(message)

Page 55: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

public class ObservationType {

private String phenomenon;

private Validator dataElementValidator = null;

private String phenomenonType;

public ObservationType() { super();}

public ObservationType(String ddElementName) {

DataDictionaryRecord ddrecord = DDManager.getMember( ddElementName );

setPhenomenon( ddElementName );

setPhenomenonType( ddrecord.getDataElementType());

try { // This uses the validator name stored in the data dictionary

// to build an instance of the needed validator class (either

// a RangeValidator or a DiscreteValidator) using Reflection

Class validatorClass = Class.forName(ddrecord.getValidatorName() );

setDataElementValidator ( (Validator) validatorClass.newInstance());

getDataElementValidator().setDDRecord( ddrecord);

} // end try

catch(Exception e) { e.printStackTrace(); }

} // end constructor

Validator ExampleObservation

Type

Page 56: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

ObservationPanel 

observationLabel 

observationTextfield

observationErrorLabel 

DataDictionaryRecord Observation 

create

isValid(obsvalue)

ObservationType

create(ddElementName)

isValid(obsvalue)

We Know: ddElementName of the field value of the text field

Class 

creategetValidatorName forName

Range 

Discrete 

Null 

create

isValid(obsvalue)setText(message)

Page 57: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

public Validator getDataElementValidator() { return dataElementValidator;}

public String getPhenomenon() { return phenomenon;}

public String getPhenomenonType() { return phenomenonType;}

public boolean isValid(String obsValue) {

return getDataElementValidator().isValid(obsValue );

} // end isValid

public void setDataElementValidator(Validator newValue) {

this.dataElementValidator = newValue;

} // end setDataElementValidator

public void setPhenomenon(String newValue) { this.phenomenon = newValue;}

public void setPhenomenonType(String newValue) { this.phenomenonType = newValue;}

}// end class

Validator ExampleObservation

Type

Page 58: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

Validator Example

ObservationPanel 

observationLabel 

observationTextfield

observationErrorLabel 

DataDictionaryRecord Observation 

create

isValid(obsvalue)

ObservationType

create(ddElementName)

isValid(obsvalue)

We Know: ddElementName of the field value of the text field

Class 

creategetValidatorName forName

Range 

Discrete 

Null 

create

isValid(obsvalue)setText(message)

Page 59: SEA Side Software Engineering Annotations Annotation 3: Analysis Patterns Professor Sara Stoecklin Director of Software Engineering- Panama City sstoecklin@mail.pc.fsu.edu.

public class RangeValidator extends Validator {

public RangeValidator() { super();}

public boolean isValid(String obs ) {

int obsInt;

if(getDDRecord().getDataElementType().equals("integer")) {

// validate that the obs is an integer other value types would follow

try { obsInt = Integer.parseInt( obs ); }

catch(NumberFormatException e) { return false; }

// validate that obs meets the rules of min and max

int maxInt = Integer.parseInt(getDDRecord().getMax());

int minInt = Integer.parseInt(getDDRecord().getMin());

return (((minInt <= obsInt )&&(maxInt>=obsInt)));

} // end if

return false;

} // end isValid

}// end class

Range 

Validator Example