Upload
andra-welch
View
222
Download
0
Embed Size (px)
DESCRIPTION
353 We want to: Refine relationships, operations, and attributes Focus on fleshing out the details of a particular class operations needed and allocated to classes; how operations / methods collaborate to support the responsibilities allocated to the class. Later: Address non- functional requirements We will look at Design Patterns in the future.
Citation preview
35 1
Class Design - Part 1
35 2
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
35 3
We want to: Refine relationships, operations, and attributes
Focus on fleshing out the details of a particular class operations needed and allocated to classes; how operations / methods collaborate to support the
responsibilities allocated to the class. Later:
Address non- functional requirements We will look at Design Patterns in the future.
35 4
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: decide on the infrastructure;
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.
35 5
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 (more cohesive…)
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.
35 6
MainForm
SubWindow
DropDownListButton
MainWindow
Recall: Boundary Classes – from Analysis External System Interface:
Note: Usually model as subsystem Oftentimes these interfaces have complex
internal behavior (hence the design modeling as a subsystem)
Analysis
Design (within Subsystem)
35 7
Recall: Entity Classes (1 of 3) Entity objects are often passive and persistent
In Analysis, we identified entity classes. These classes may have been associated with analysis mechanisms for persistence representing manipulated units of information. (recall java.sql classes) May be associated with legacy systems too. May be distributed… Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model.
35 8
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 Re-factoring Have persistent class with five attributes. One attribute is not really persistent – used during runtime but 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:
35 9
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.
So, which would you ratherSo, which would you rather retrieve?? FatClass or retrieve?? FatClass or FatClassDataHelper?FatClassDataHelper?
35 10
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 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 or more design classes.
35 11
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 are mapped to a storage
mechanism.
35 12
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.
ClientClass
Persistency
AnalysisMechanism
(Conceptual)
DesignMechanism(Concrete)
ImplementationMechanism
(Actual)
OODBMS
RDBMS JDBC to Ingres
ObjectStore
Legacy Data
New Data
Course
StudentPersistency
35 13
Important Note. Persistent classes may come from entity classes. May also be needed to handle some non-
functional requirements…
Examples: Persistent objects needed to maintain information
relevant to process control, or Persistent objects needed to maintain state information
between transactions.
35 14
A Closer look at Classes
35 15
Class Operations Purpose
Map responsibilities (analysis) to operations (design) that implement them
Things to consider regarding class operations: 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.
35 16
Class Operations: Name and Describe
Provide appropriate operation names.Indicate 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 – if you know it.
Thus the interfaces will already be specified in terms of the implementation language when coding starts.
Helpful to provide short textual description, including meaning of all parameters for an operation.
35 17
Class Operation Signatures: Guidelines In addition to a short description of the parameter, be sure to include:
Parameters passed by-value or by-reference? If Call by Value, parameter cannot be changed in call. If Call by Reference, parameter may be changed in call.
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.
35 18
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.• Dependency also applies to attributes as well as operations..
What does the class diagram above tell you???
35 19
Class- privateAttribute# protectedAttribute
+publicOp()# protectedOp()- privateOp()
Class Visibility – How 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.
35 20
Class
- classifierScopeAttribute
classifierScopeOperation()
- instanceScopeAttribute
instanceScopeOperation()
Class Operation and Attribute Scope. Determines number of instances of attribute or
operation Instance scope: one instance for each class instance (object)
(instance variables…) Class scope: one instance for all class instances (objects)
Static variables in Java. Don’t need instantiations… Class scope: underline attribute/operation name
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. (in Java, class scope static)
35 21
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 class scoped attribute, nextAvailID; single classifier scoped operation, getNextAvailID().
• Each Student instance has it’s own unique student-ID, name, address, whereas, there is only one nextAvailID for all Student instances.
• The getNextAvailID() classifier scoped operation can only access nextAvailID.• Why??
35 22
Example: See Visibility indicators…
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..10..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 )
35 23
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 (i.e., classes….) 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
35 25
Defining Dependenciesand Associations
26
What Is a Dependency? A relationship between two objects
In Analysis, we assumed relationships were ‘structural’that is,
associations, aggregations, composition.
These refer to parts, numbers, coincident lifetimes, one–to– many, etc.
In Design, we must decide what type of communication pathway is required.
Define Dependency
Dependency - more A dependency relationship denotes a semantic
relationship between model elements, where a change in the supplier may cause a change in the client.
Semantics focuses on the relation between signifiers, such as words, phrases, signs, symbols, ….
What would happen if java.sql changed, where all of our, say, persistency mechanisms use (depend on) the objects in this package?
Need to Determine what causes the supplier to be visible to the client
35 27
35
Client Supplier
Usually the association will have numbers relating objects of one type to the other; roles too…
28
Associations are structural relationships i.e., numbers of one type related to another; parts, lifetimes, ….
Dependencies are non-structural (semantic) relationships. Dependencies are strong relationships!
Association
Client
Supplier1
Supplier2
Dependency
Dependencies vs. Associations*
1
0..1 buyerbroker
35 29
Communication pathways to Suppliersa.k.a. how are suppliers made visible to clients Four communications pathways to supplier; that is, how are
suppliers made ‘visible’ to clients. Local variable reference –
Supplier object is declared locally (created temporarily during execution of an operation / method)
Client object declares a local variable within a specific method within client.
Parameter reference – supplier object is a parameter to, or the return class of an operation
in the client object. A method in client has a formal parameter of type supplier or
the method returns an object of type supplier… Global reference – supplier object is global.
Self-explanatory Field reference – The supplier object is a data member in
the client object. There is an instance variable within object of type supplier.
35 30
Associations and aggregations are structural relationships (Visibility = Field Visibility; four slides up).
We’re talking about ‘Association relationships’ realized by variables that exist in the data member section of the class definition.
Field: ALL objects have own copy of instance variables!
Each class stands on it's own.
Dependency is a type of communication pathway that is a more temporary type of relationship – (Visibility = Global, Parameter, & Local; next three slides)
(Parameter – method may/may not be invoked; Local? Temporary life for execution of method; Global– life apart from object…)
Any relationships not associations are dependency
Dependencies vs. Associations: Look at Relationships: What are they going to be/become?
35 31
ClassA
op1 ()
ClassB
Local Variable Visibility Dependency The op1() operation contains a local
variable (an object) of type ClassB (local variable is not a parameter)
Hence there is a dependency between these two classes.
boolean op1(….) // method in ClassA { ClassB myClassB = new ClassB (…) …
35 32
ClassA
op1 (param1: ClassB)
ClassB
Parameter Visibility Dependency The ClassB instance is passed to the
ClassA instance – hence a dependency.
Format: object name; Class e.g. op1(myClassB: ClassB)
If op1 is invoked, it is passed an object of type ClassB
35 33
ClassUtility
utilityOp ()
ClassA
op1 ()
Global Visibility Dependency The ClassUtility instance is visible
because it is global. Clear dependency. op1() uses something in ClassUtility
35 34
ClassB
utilityOp ()
ClassA
ClassB myClassB; op1 ()
Field Visibility Association The ClassB instance is visible. There is an
‘association.’ Not temporary; Every instance has copy
instance variable
35 35
Example:Define Dependencies (before looking for dependecies) (VOPC Register for Courses Use Case)
ICourseCatalogSystem
+ getCourseOfferings(forSemester : Semester) : CourseOfferingList
(from External System Interfaces)
<<Interface>>
Student
- name- address- StudentID : int
+ addSchedule(theSchedule : Schedule, forSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean
(from University Artifacts)
<<entity>>
RegistrationController
+ // submit schedule()+ // save schedule()+ // create schedule with offerings()+ // getCourseOfferings(forSemester) : CourseOfferingList
(from Registration)
<<control>>
0..1
0..1registrant
0..*1
courseCatalog
Schedule
- semester
+ submit()+ // save()# any conflicts?()+ // create with offerings()
(from University Artifacts)
<<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()
(from University Artifacts)
<<entity>>
0..*
0..4
primaryCourses
0..*
0..2alternateCourses
Up to here, most relationships have been associations and aggregations. Now, will see how some of these are refined into dependencies.Too, a lot of this was done during analysis!
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.
35 36
Example: Define Dependencies (after 1 of 2)
Global visibility
Parameter visibility
ICourseCatalogSystem
+ getCourseOfferings(forSemester : Semester) : CourseOfferingList
(from External System Interfaces)
<<Interface>>
Student
- name- address- StudentID : int
+ addSchedule(theSchedule : Schedule, forSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean
(from University Artifacts)
<<entity>>
RegistrationController
+ // submit schedule()+ // save schedule()+ // create schedule with offerings()+ // getCourseOfferings(forSemester) : CourseOfferingList
(from Registration)
<<control>>
0..1
0..1registrant
Schedule
- semester
+ submit()+ // save()# any conflicts?()+ // create with offerings()
(from University Artifacts)
<<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()
(from University Artifacts)
<<entity>>
0..*
0..4primaryCourses
0..*
0..2alternateCoursesField visibility
Field
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 his/her own Schedules, so Field visibility is chosen from Student to Schedule – and relation remains aggregation. Again, more‘permanent.’ More see Course Offering in
Student as parameter
see Schedule as parameter below
35 37
Example: Define Dependencies (after; more explanation)
Global visibility
Parameter visibility
ICourseCatalogSystem
+ getCourseOfferings(forSemester : Semester) : CourseOfferingList
(from External System Interfaces)
<<Interface>>
Student
- name- address- StudentID : int
+ addSchedule(theSchedule : Schedule, forSemester : Semester)+ getSchedule(forSemester : Semester) : Schedule+ hasPrerequisites(forCourseOffering : CourseOffering) : boolean# passed(theCourseOffering : CourseOffering) : boolean
(from University Artifacts)
<<entity>>
RegistrationController
+ // submit schedule()+ // save schedule()+ // create schedule with offerings()+ // getCourseOfferings(forSemester) : CourseOfferingList
(from Registration)
<<control>>
0..1
0..1registrant
Schedule
- semester
+ submit()+ // save()# any conflicts?()+ // create with offerings()
(from University Artifacts)
<<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()
(from University Artifacts)
<<entity>>
0..*
0..4primaryCourses
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.