Class Design Another Look – Part 1. Note: there is so much more than below… More facts...

Class DesignAnother Look – Part 1

Note: there is so much more than below…

More facts regarding Class DesignRe-look at Persistent ClassesRe-look at Class Operations

Scope of OperationsMethodsStates – State ChartsAttributes

Defining Dependenciesand Associations

GeneralizationsMultiple InheritancePolymorphism

We want to:

Refine relationships, operations, and attributes

Focus on fleshing out the details of a particular class – operations needed and allocated to classes and how they collaborate to support the responsibilities allocated to the class.

Address non- functional requirements

We will look at Design patterns in the very near future.

Class Design in Context*

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

ClassDesign

Subsystem Design

Use-Case Design

DesignReviewer

This is where we stand. Recall:Architectural Design is where we decide what the infrastructure is (pieces and parts of the architecture and how they interact). Use Case Design is where the responsibilities of the system are allocated to the pieces/parts; Subsystem and Class design are where we detail the specifics of the pieces/parts.

Class Design in Context*

Architect

Designer

ArchitecturalAnalysis

ArchitectureReviewer

Review theDesign

Review theArchitecture

Use-CaseAnalysis

ArchitecturalDesign

DescribeConcurrency

DescribeDistribution

Class Design

Subsystem Design

Use-Case Design

DesignReviewer

During Class Design, we consider: implementation and deployment environments. May need to adjust the classes to the particular products in use, the programming languages, distribution, performance, use of component architectures like COM or CORBA, and other constraints • Frequent iteration between Class Design, Subsystem Design and Use Case Design.• Class Design - performed for each class in current iteration.

A class should have a single well focused purpose.

A class should do one thing and do it well!

How Many Classes Are Needed? Many, simple classes means that each class

Encapsulates less of the overall system intelligence

Is more reusable Is easier to implement

Few, complex classes means that each class Encapsulates a large portion of the overall system

intelligence Is less likely to be reusable Is more difficult to implement

Proper size may depend heavily on implementation environment – classes should map directly to some phenomenon in the implementation language in such a way that the mapping results in good code.

MainForm

SubWindow

DropDownListButton

MainWindow

Recall: Boundary Classes – External System Interface:* Note:

Usually model as subsystem (recall Billing System interface?)

Oftentimes these interfaces have complex internal behavior (hence the modeling as a subsystem)

Recall: Entity Classes (1 of 3) Entity objects are often passive and persistent

In Analysis, we identified entity classes.

May have been associated with analysis mechanisms for persistence representing manipulated units of information.

Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model. (Re-factoring covered ahead) Maybe only ‘parts’ of objects need persistency….

Analysis Design

FatClass- transientBookeeping

+ getCommonlyUsedAtt1()+ getCommonlyUsedAtt2()+ getRarelyUsedAtt3()+ getRarelyUsedAtt4()

FatClassDataHelper

+ commonlyUsedAtt1+ commonlyUsedAtt2

FatClassLazyDataHelper

+ rarelyUsedAtt3+ rarelyUsedAtt4

1 1

FatClass

- transientBookeeping+ commonlyUsedAtt1+ commonlyUsedAtt2+ rarelyUsedAtt3+ rarelyUsedAtt4

<< entity >>

Entity Classes - Sample of Re-factoring Have persistent class with five attributes. One attribute is not really persistent – used during runtime Use Cases tell us two attributes used a lot; two others less. In design, we would like to retrieve commonly used

attributes right away but defer others until asked for. But we don’t want a complex design for the client. So:

AnalysisDesign

FatClass

- transientBookeeping

+ getCommonlyUsedAtt1()+ getCommonlyUsedAtt2()+ getRarelyUsedAtt3()+ getRarelyUsedAtt4()

FatClassDataHelper

+ commonlyUsedAtt1+ commonlyUsedAtt2

FatClassLazyDataHelper

+ rarelyUsedAtt3+ rarelyUsedAtt4

1 1

FatClass

- transientBookeeping+ commonlyUsedAtt1+ commonlyUsedAtt2+ rarelyUsedAtt3+ rarelyUsedAtt4

<< entity >>

Entity Classes From a data standpoint, will consider the FatClass to be a

proxy in front of the two real persistent data classes. It will retrieve FatClassDataHelper from database when it is

first retrieved. Will retrieve FatClassLazyDataHelper in rare occasion when a client asks for one of these attributes.

This is a view from a data-oriented perspective while retaining a logical object-oriented view for clients to use.

It is tuning for performance too.

So, which would you ratherSo, which would you rather retrieve?? FatClass or retrieve?? FatClass or FatClassDataHelper?FatClassDataHelper?

Recall: Control Classes What Happens to Control Classes?

Are they really needed? Split them? If they seem like just ‘pass throughs’ from the

boundary to the entity classes, eliminate them.

Control Classes may become true design classes for any of following reasons: Encapsulate significant control flow behavior High probability of Change Behaviors are to be distributed across multiple

processes and/or processors (often JSP, servlets…) The behavior they encapsulate requires some

transaction management

A single analysis control class can easily become two classes in design

Class Design Steps – Identify Persistent Classes

In Use-Case Analysis, a vague notion that certain classes need to be

persistent But this is just the 'tip of the iceberg' of system design.

Now, in Class Design, get really specific about what the classes are, (are there more?) what their behaviors are (parameters, et al), and what attributes these classes really have.

Now, we must be certain which classes will have persistent instances, and that all persistent classes should be mapped to a

storage mechanism.

Persistent class? Any instance of the class that requires its state to be preserved. A persistent class may have both persistent and

transient instances labeling a class 'persistent' means merely that

some instances of the class may need to be persistent.

Client

Class

Persistency

Analysis

Mechanism

(Conceptual)

Design

Mechanism

(Concrete)

Implementation

Mechanism

(Actual)

OODBMS

RDBMS JDBC to Ingres

ObjectStore

Legacy Data

New Data

Course

StudentPersistency

Important Note.

Persistent classes may not only come from entity classes.

Could also be other classes required to handle other non-functional requirements in general.

Examples: Persistent objects needed to maintain

information relevant to process control, or Persistent objects needed to maintain state

information between transactions.

Re-look at Class Operations

Purpose Map responsibilities (analysis) to operations

(design) that implement them Things to consider :

Operation name, signature, and description Operation visibility Operation scope

Class operation vs. instance operation Operations: define at most primitive level to

promote reusability and maintainability.

Operations: Name and Describe

Appropriate operation namesIndicate the outcome – e.g. getBalance(). Consistent across classes

Define operation signatures operationName(parameter : class,..) : returnType Best to specify operations and their parameters

using implementation language syntax and semantics.

Thus the interfaces will already be specified in terms of the implementation language when coding starts.

Always provide short textual description, including meaning of all parameters for an operation!!!

Operation Signatures: Guidelines

In addition to a short description of the parameter, be sure to include: Parameters passed by-value or by-reference?

If by value, parameter cannot be changed. If by reference, is parameter(s) changed?

Parameters optional? Default parameter values? Valid parameter ranges?

The fewer the parameters, the better. less coupling; more understandable and

maintainable.

Pass objects instead of “data bits” – a rich strength of OO.

Discovering Additional Classes and Relationships

Additional classes and relationships may be added to support signature

ClassA Class2

op1(var1:Class2): Class3

Class3

• Parameters and return types may lead to discovery of other classes.• Operation parameters and return classes denote a relationship between these classes and the parameter class and/or the return class.

• In many cases, the relationships added to support operation signatures are dependency relationships.

• Dependency relationships are discussed ahead.• This applies to attributes as well as operations..

What does the class diagram above tell you???

Class

- privateAttribute# protectedAttribute

+publicOp()# protectedOp()- privateOp()

How Is Visibility Noted?

The following symbols are used to specify export control for attributes and operations: + Public access # Protected access - Private access In Java we also have package visibility. Symbol??

More on Classes

Class

- classifierScopeAttribute

classifierScopeOperation()

- instanceScopeAttribute

instanceScopeOperation()

Scope of Operation and Attributes Determines number of instances of the attribute or

operation. Instance scope: one instance for each class instance Class scope: one instance for all class instances

Class scope: underline attribute/operation name Cannot do this in Rose, but can use stereotype

<<class>> to indicate class scope Generally, we have instance scope; but can have class

scope for may other practical reasons: counters, etc. Class scoped operations can only access class-scoped

attributes.

Example: ScopeStudent

- name- address

- nextAvailID : int

+ addSchedule(theSchedule : Schedule, forSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean+ getNextAvailID() : int

<<entity>>

- studentID

• Here, have a single classifier scoped attribute, nextAvailID; single classifier scoped operation, getNextAvailID().• These support the generation of a unique ID for each Student.

• Each Student instance has it’s own unique Student-ID, whereas, there is only one nextAvailID for all Student instances.

• The getNextAvailID() classifier scoped operation can only access nextAvailID.

MathFunctions<<utility>>

Utility Classes

What is a Utility Class? Utility is a class stereotype Used for a class that contains a collection of free

subprograms Free subprograms are nonmember functions, that is,

functions that do not belong to a particular class. Why use it?

To provide services that may be (re)useful in a variety of contexts (e.g. common algorithmic services)

Or, to wrap non object-oriented libraries or applications In Use

No ‘instances’ of a utility class; all attributes / ops are considered classifier scoped (class scope).

Utility classes are not formal UML constructs, but can be defined for programming convenience. (Will see more ahead)

Example: Utility Classes*

<<utility>> MathPack

-randomSeed : long = 0randomSeed : long = 0--pi : double = 3.14159265358979pi : double = 3.14159265358979

+sin (angle : double) : double+cos (angle : double) : double+random() : double

Note: all properties and methods are class-scoped.

Discuss syntax of class…

Example: Portion of VOPC for the Register for Courses

Use Case Realization

CourseOffering(from University Artifacts)

<<entity>>

Student.

+ getTuition() : double+ addSchedule(theSchedule : Schedule)+ getSchedule(forSemester : Semester) : Schedule+ deleteSchedule(forSemester : Semester)+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean<<class>> + getNextAvailID() : int+ getStudentID() : int+ getName() : string+ getAddress() : string

(from University Artifacts)

<<entity>>

RegistrationController

+ submitSchedule()+ saveSchedule()+ getCourseOfferings() : CourseOfferingList+ getCurrentSchedule(forStudent : Student, forSemester : Semester) : Schedule+ deleteCurrentSchedule()<<class>> + new(forStudent : string)+ getStudent(withID : string) : Student

(from Registration)

<<control>>

Schedule(from University Artifacts)

<<entity>>

0..1

0..1+registrant

0..*

1

0..1

0..1

+currentSchedule

0..*

0..*

+primaryCourses

0..4

+alternateCourses

0..2

ICourseCatalogSystem

+ getCourseOfferings()+ initialize()

(from External System Interfaces)

<<Interface>>

10..*

Note: the <<class>> operations.Note: + classes (invoked by clients); # - only invoked by defining class/subclasses,

(usually correspond to reflexive operations on interaction diagrams; (more )


Use Case Realization*


<<entity>>

Student.

+ getTuition() : double+ addSchedule(theSchedule : Schedule)+ getSchedule(forSemester : Semester) : Schedule+ deleteSchedule(forSemester : Semester)+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean<<class>> + getNextAvailID() : int+ getStudentID() : int+ getName() : string

+ getAddress() : string


<<entity>>



(from Registration)

<<control>>


<<entity>>

0..1

0..1+registrant

0..*

1

0..1

0..1

+currentSchedule

0..*

0..*

+primaryCourses

0..4

+alternateCourses

0..2




<<Interface>>

10..*

Dependency from Student to CourseOfferingClass was added to support the inclusion of the CourseOffering as a parameter to operationswithin the Student Class.Do you understand what this means??



<<entity>>

Student.

+ getTuition() : double+ addSchedule(theSchedule : Schedule)+ getSchedule(forSemester : Semester) : Schedule+ deleteSchedule(forSemester : Semester)+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean<<class>> + getNextAvailID() : int+ getStudentID() : int+ getName() : string

+ getAddress() : string


<<entity>>



(from Registration)

<<control>>


<<entity>>

0..1

0..1+registrant

0..*

1

0..1

0..1

+currentSchedule

0..*

0..*

+primaryCourses

0..4

+alternateCourses

0..2




<<Interface>>

10..*

Semester is included as the type for several parameters in Student ops. For Course RegistrationSystem, it is considered to be an abstract data type that has no significant behavior and thus is not modeled as a separate class.

(Attribute compartments supressed here)

?

Review: Package Element VisibilityPackageA

Class A1

Class A3

Class A2A

BPackageB

+Class B1

-Class B2Class has Public visibility

Class has Private visibility

Only public classes can be referenced outside of the owning package

Can specify visibility for package elements in same way as class attributes / operations (can protect classes)

Shows how other packages can access the elements owned by the package.

(Have visibility symbols for packages)

OO Principle: Encapsulation

Review: Package Element Visibility PackageA

Class A1

Class A3

Class A2A

BPackageB

+Class B1

-Class B2Class has Public visibility

Class has Private visibility

OO Principle: Encapsulation

Public classes can be accessed outside of owning package.

Protected classes only be accessed by owning package & any packages that inherit from owning package.

Private classes can only be accessed by classes within owning package.

Public elements of package constitute package’s interface.

Defining Dependenciesand Associations

What Is a Dependency? A relationship between two objects In analysis, we assumed relationships were ‘structural’

that is, associations or aggregations- parts, numbers, coincident lifetimes, one – to – many, etc.

In design, we must decide what type of communication pathway is required.

A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client.

Need to Determine where structural relationships are NOT

required What causes the supplier to be visible to the client

Client Supplier

Define Dependency

Read these carefully: Associations are structural relationships Dependencies are non-structural relationships

Association

Client

Supplier1

Supplier2

Dependency

Dependencies vs. Associations*

Communication pathways to suppliers*** Four communications pathways to supplier…

Local variable reference – supplier object is declared locally (created temporarily during execution of an operation)

Parameter reference – supplier object is a parameter to, or the return class of, an operation in the client object.

Global reference – supplier object is global. Field reference – The supplier object is a

data member in the client object.

Associations and aggregations are structural relationships (field visibility). We’re talking about ‘Association relationships’

realized by variables that exist in the data member section of the class definition.

Dependency is a type of communication pathway that is a more temporary type of relationship –global, parameter, local visibility Any relationships not associations are

dependencyAssociation

ClientSupplier1 Supplier2

Dependency

Dependencies vs. Associations: Look at relationships: What are they going to be/become?

ClassA

op1 ()

ClassB

Local Variable Visibility Dependency

The op1() operation contains a local variable of type ClassB. Hence there is a dependency between these two classes.

ClassA

op1 (param1: ClassB)

ClassB

Parameter Visibility Dependency

The ClassB instance is passed to the ClassA instance – hence a dependency.

ClassUtility

utilityOp ()

ClassA

op1 ()

Global Visibility Dependency

The ClassUtility instance is visible because it is global. Clear dependency.

Strive for real-world relationships

Strive for the lightest relationships possible (dependency) Dependency is the cheapest to keep, easiest to utilize

and benefit from encapsulation.

Sometimes a relationship may be more permanent (aggregation) and sometimes the same kind of relationship might be a dependency.

Identifying Dependencies: Considerations


Is relationship “permanent”? Use association (field visibility)

Will I need this relationship again and again over time, or do I just need it to do some work and then I throw it away?

If I need it again and again, i.e., if a thing appears to remain related to another thing even across the execution of one or more operations, then it is likely as association and therefore should benefit from field visibility.

Is relationship “temporary”? Use dependency Multiple objects at run time share the same

instance again and again, probably should be passing it as a parameter…(parameter visibility)

Or if there is only one in existence in whole process, set it up as a managed global (Singleton design pattern – next week)

If same instance is not shared, then a local copy should suffice; i.e., multiple objects don’t share the same instance – use local visibility.


No exact recipe for decision

How long does it take to create/destroy?

Expensive to connect/disconnect every time I need it? If so, use field, parameter (association), or global

visibility (dependency).

All variations of dependencies are dependent on situations.

Choice? Design it however it works best in your circumstances…


Example:Define Dependencies (before) VOPC Register for Courses Use Case


+ getCourseOfferings(forSemester : Semester) : CourseOfferingList


<<Interface>>

Student

- name- address- StudentID : int

+ addSchedule(theSchedule : Schedule, forSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean


<<entity>>


+ // submit schedule()+ // save schedule()+ // create schedule with offerings()+ // getCourseOfferings(forSemester) : CourseOfferingList

(from Registration)

<<control>>

0..1

0..1

registrant

0..*1

courseCatalog

Schedule

- semester

+ submit()+ // save()# any conflicts?()+ // create with offerings()


<<entity>>

0..*

1

0..1 0..1

currentSchedule

CourseOffering

- number : String = "100"- startTime : Time- endTime : Time- days : Enum

+ addStudent(studentSchedule : Schedule)+ removeStudent(studentSchedule : Schedule)+ new()+ setData()


<<entity>>

0..*

0..4

primaryCourses

0..*

0..2

alternateCourses

Up to here, most relationships have been associations and aggregations. Now, will see how some of these are refined into dependencies.

The dependency shown (next slide) was previously defined in the Define Ops section to support the Schedule operation signatures.

All associations/aggregations should be examined to see if they are dependencies.

Example: Define Dependencies (after)

Global visibility

Parameter visibility




<<Interface>>

Student




<<entity>>



(from Registration)

<<control>>

0..1

0..1registrant

Schedule

- semester



<<entity>>

0..*

1

0..1 0..1

currentSchedule

CourseOffering




<<entity>>

0..*

0..4

primaryCourses

0..*

0..2alternateCoursesField visibility

Field visibility

Changed one association to a dependency relationship. (This change discussed on ‘next’ slide) Here, during a registration session, the Registration Controller works with a single Student, the registrant, and one Schedule, the current Schedule for the Student.

These instances need to be accessed by more than one of the Registration Controller’s, operations so Field Visibility is chosen from Registration Controller to Student and from Registration Controller to Schedule.Thus relationships remain associations.(more ‘permanent’)

A Student manages its own Schedules, so Field visibility is chosen from Student to Schedule – and relation remains aggregation. Again, more‘permanent.’ More

Example: Define Dependencies (after)

Global visibility

Parameter visibility




<<Interface>>

Student




<<entity>>



(from Registration)

<<control>>

0..1

0..1registrant

Schedule

- semester



<<entity>>

0..*

1

0..1 0..1

currentSchedule

CourseOffering




<<entity>>

0..*

0..4

primaryCourses

0..*

0..2alternateCoursesField visibility

Field visibility

Course Offerings are part of semantics of what defines a Schedule (courses Student has selected). Thus Field visibility is chosen from Schedule to CourseOffering; relationships remain associations.

The Student class has several operations where CourseOffering appears in the parameter list. Thus, Parameter visibility is chosen from Student to CourseOffering.

It is envisioned the course Catalog System may need to be accessed by multiple clients in the system, so Global visibility was chosen – and relationship becomes a dependency.

Date post:	22-Dec-2015
Category:	Documents
View:	216 times
Download:	0 times

Class Design Another Look – Part 1. Note: there is so much more than below… More facts...

Documents