Class Design Part 1 35 1 Note there

Class Design - Part 1 35 1

Note: there is so much more than below… o More facts regarding Class Design Re-look at Persistent Classes Re-look at Class Operations o Scope of Operations Methods States – State Charts Attributes o Defining Dependencies and Associations o Generalizations Multiple Inheritance Polymorphism 35 2

We want to: o Refine relationships, operations, and attributes o Focus on fleshing out the details of a particular class n operations needed and allocated to classes; n how operations / methods collaborate to support the responsibilities allocated to the class. o Later: n Address non- functional requirements n We will look at Design Patterns in the future. 35 3

Class Design in Context Architectural Analysis Describe Architectural Concurrency Design Architect Review the Architecture Reviewer Subsystem Design Use-Case Analysis Designer Describe Distribution Review the Design Use-Case Design Reviewer Class Design 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 4

How Many Classes Are Needed? Many, simple classes means that each class n Encapsulates less of the overall system intelligence n Is more reusable n Is easier to implement (more cohesive…) o Few, complex classes means that each class n Encapsulates a large portion of the overall system intelligence n Is less likely to be reusable n Is more difficult to implement o 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. A class should have a single well focused purpose. A class should do one 35 thing and do it well! 5

Recall: Boundary Classes – from Analysis External System Interface: o Note: n Usually model as subsystem n Oftentimes these interfaces have complex internal behavior (hence the design modeling as a subsystem) Design (within Subsystem) Analysis Main. Window Sub. Window Main. Form Button 35 Drop. Down. List 6

Recall: Entity Classes (1 of 3) o Entity objects are often passive and persistent o In Analysis, we identified entity classes. n These were ‘conceptual’ classes. Often taken from domain model and expanded a bit. But these were not software classes. n These classes may have been associated with analysis mechanisms for persistence, security, etc. representing manipulated units of information. n May be associated with legacy systems too. n May be distributed… n Performance concerns may suggest re-factoring of persistent classes, causing changes to the Design Model. 35 7

Entity Classes - Sample Re-factoring o Have persistent class with five attributes. o One attribute is not really persistent – used during runtime but Use Cases tell us two attributes used a lot; two others less. o In design, we would like to retrieve commonly used attributes right away but defer others until asked for. o But we don’t want a complex design for the client. So: Analysis << entity >> Fat. Class - transient. Bookeeping + commonly. Used. Att 1 + commonly. Used. Att 2 + rarely. Used. Att 3 + rarely. Used. Att 4 Fat. Class - transient. Bookeeping + get. Commonly. Used. Att 1() + get. Commonly. Used. Att 2() + get. Rarely. Used. Att 3() + get. Rarely. Used. Att 4() 1 Fat. Class. Data. Helper + commonly. Used. Att 1 + commonly. Used. Att 2 35 Design 1 Fat. Class. Lazy. Data. Helper + rarely. Used. Att 3 + rarely. Used. Att 4 8

Entity Classes o From a data standpoint, will consider the Fat. Class to be a proxy in front of the two real persistent data classes. o It will retrieve Fat. Class. Data. Helper from database when it is first retrieved. Will retrieve Fat. Class. Lazy. Data. Helper in rare occasion when a client asks for one of these attributes. o This is a view from a data-oriented perspective while retaining a logical object-oriented view for clients to use. Fat. Class Analysis << entity >> Fat. Class - transient. Bookeeping + commonly. Used. Att 1 + commonly. Used. Att 2 + rarely. Used. Att 3 + rarely. Used. Att 4 - transient. Bookeeping + get. Commonly. Used. Att 1() + get. Commonly. Used. Att 2() + get. Rarely. Used. Att 3() + get. Rarely. Used. Att 4() 1 Fat. Class. Data. Helper + commonly. Used. Att 1 35 + commonly. Used. Att 2 Design So, which would you rather retrieve? ? Fat. Class or Fat. Class. Data. Helper? 1 Fat. Class. Lazy. Data. Helper + rarely. Used. Att 3 + rarely. Used. Att 4 9

Recall: Control Classes o What Happens to Control Classes? n Are they really needed? Split them? n If they seem like just ‘pass throughs’ from the boundary to the entity classes, eliminate them. n Recall the purpose of Control Classes…. o Control Classes may become true design classes for any of following reasons: n Encapsulate significant control flow behavior n Behaviors are to be distributed across multiple processes and/or processors (often JSP, servlets…) n The behavior they encapsulate requires some transaction management o A single analysis control class can easily become two or more design classes. 35 10

Class Design Steps: Identify Persistent Classes o In Use-Case Analysis, (that is, going through use cases…) n a vague notion that certain classes need to be persistent n But this is just the 'tip of the iceberg' of system design. o Now, in Class Design, get really specific about n what the classes are, (are there more? ) n what their behaviors are (parameters, services, …et al), and n what attributes these classes really have. o Now, we must be certain n which classes will have persistent instances, and that n all persistent classes are mapped to a storage mechanism. 35 11

o Persistent class: Any instance of the class that requires its state to be preserved. n A persistent class may have both persistent and transient instances n Labeling a class 'persistent' means merely that some instances of the class may need to be persistent. Client Analysis Design Implementation Class Mechanism (Conceptual) (Concrete) (Actual) Legacy Data Course Student Persistency RDBMS SQL Server New Data Sybase; Oracle… OODBMS 35 Object. Store 12

Important Note. o Persistent classes may come from entity classes. o May also be needed to handle some non-functional requirements… o Examples: n Persistent objects needed to maintain information relevant to process control, or n Persistent objects needed to maintain state information between transactions. 35 13

A Closer look at Classes 35 14

Class Operations o Purpose n Map responsibilities (analysis) (from use cases or user stories) to operations (design) that implement them o Things to consider regarding class operations: n Operation name, signature, and description n Operation visibility n Operation scope o Class operation vs. instance operation o Operations: define at most primitive level to promote reusability and maintainability. 35 15

Class Operations: Name and Describe o Provide appropriate operation names. Indicate the outcome – e. g. get. Balance(). Consistent across classes o Define operation signatures n operation. Name(parameter : class, . . ) : return. Type n Best to specify operations and their parameters using implementation language syntax and semantics – if you know it. n Thus the interfaces will already be specified in terms of the implementation language when coding starts. n Helpful to provide short textual description, including meaning of all parameters for an operation. o (still not doing real detailed design; that is, the algorithm. This is done during programming. ) 35 16

Class Operation Signatures: Guidelines o In addition to a short description of the parameter, be sure to include: n Parameters passed by-value or by-reference? o If Call by Value, parameter cannot be changed in call. o If Call by Reference, parameter may be changed in call. n Parameters optional? n Default parameter values? n Valid parameter ranges? o (different implementations offer different options… o The fewer the parameters, the better. n less coupling; more understandable and maintainable. o Pass objects instead of “data bits” – 35 a rich strength of OO. 17

Discovering Additional Classes and Relationships Class. A Class 2 op 1(var 1: Class 2): Class 3 • 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. Class 3 • In many cases, the relationships added to support operation signatures are dependency What does the class relationships. (This is a strong dependency!!) diagram above tell you? ? ? • Dependency relationships are discussed ahead. • Dependency also applies to attributes as well as operations. . 35 Additional classes and relationships may be added to support signature 18

Class Visibility – How Noted? o The following symbols are used to specify export control for attributes and operations: n + Public access n # Protected access n - Private access n In Java we also have package visibility. Class - private. Attribute # protected. Attribute +public. Op() # protected. Op() - private. Op() 35 19

Class Operation and Attribute Scope. o Determines number of instances of attribute or operation n Instance scope: one instance for each class instance (object) (instance variables…) n Class scope: one instance for all class instances (objects) o Static variables in Java. Don’t need instantiations… o Class scope: underline attribute/operation name n Generally, we have instance scope; but can have class scope for may other practical reasons: counters, global data (cough) etc. n Class scoped operations can only access class-scoped attributes. (in Java, class scope static) Class - classifier. Scope. Attribute - instance. Scope. Attribute classifier. Scope. Operation() 35 instance. Scope. Operation() 20

Example: Scope <<entity>> Student - name - address - student. ID - next. Avail. ID : int + add. Schedule(the. Schedule : Schedule, for. Semester : Semester) + get. Schedule(for. Semester : Semester) : Schedule + has. Prerequisites(for. Course. Offering : Course. Offering) : boolean # passed(the. Course. Offering : Course. Offering) : boolean + get. Next. Avail. ID() : int • Here, have a single class scoped attribute, next. Avail. ID; single classifier scoped operation, get. Next. Avail. ID(). • Each Student instance has it’s own unique student-ID, name, address, whereas, there is only one next. Avail. ID for all Student instances. • The get. Next. Avail. ID() classifier scoped operation can only access next. Avail. ID. • Why? ? 35 21

Example: See Visibility indicators… <<control>> Registration. Controller 0. . * (from Registration) 1 <<Interface>> ICourse. Catalog. System (from External System Interfaces) + get. Course. Offerings() + submit. Schedule() + initialize() + save. Schedule() + get. Course. Offerings() : Course. Offering. List + get. Current. Schedule(for. Student : Student, for. Semester : Semester) : Schedule + delete. Current. Schedule() +current. Schedule <<class>> + new(for. Student : string) 0. . 1 <<entity>> + get. Student(with. ID : string) : Student Schedule 0. . 1 (from University Artifacts) 0. . 1 0. . * +registrant 0. . 1 <<entity>> Student. 1 +alternate. Courses +primary. Courses (from University Artifacts) + get. Tuition() : double + add. Schedule(the. Schedule : Schedule) + get. Schedule(for. Semester : Semester) : Schedule + delete. Schedule(for. Semester : Semester) + has. Prerequisites(for. Course. Offering : Course. Offering) : boolean # passed(the. Course. Offering : Course. Offering) : boolean <<class>> + get. Next. Avail. ID() : int + get. Student. ID() : int + get. Name() : string + get. Address() : string 0. . 2 0. . 4 <<entity>> Course. Offering (from University Artifacts) Note: the <<class>> operations. Note: + classes (invoked by clients); # only invoked by defining class/subclasses, 35 22 (usually correspond to reflexive operations on interaction diagrams; (more )

Review: Package Element Visibility Package. A Class A 1 Class A 2 A Class A 3 Package. B B +Class B 1 Class has Public visibility Class has Private visibility -Class B 2 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: 35 Encapsulation 23

Defining Dependencies and Associations 35 25

Define Dependency o What Is a Dependency? n A relationship between two objects n In Analysis, we assumed relationships were ‘structural’ that is, associations, aggregations, composition. These refer to parts, numbers, coincident lifetimes, one–to– many, etc. n In Design, we must decide what type of communication pathway is required. 26

Dependency - more o A dependency relationship denotes a semantic relationship between model elements, where a change in the supplier may cause a change in the client. o Semantics focuses on the relation between signifiers, such as words, phrases, signs, symbols, …. o What would happen if java. sql changed, where all of our, say, persistency mechanisms use (depend on) the objects in this package? o Need to n Determine what causes the supplier to be visible to the client 35 Client Supplier 35 27

Dependencies vs. Associations* o Associations are structural relationships n n i. e. , numbers of one type related to another; parts, lifetimes, …. Aggregates (has_a) generalization (is_a), … o Dependencies are non-structural (semantic) relationships. Dependencies are strong relationships! Supplier 2 Dependency Association 1 Supplier 1 0. . 1 Client buyer broker Usually the association will have numbers relating objects of one type to the other; roles too… 28

Communication pathways to Suppliers a. k. a. how are suppliers made visible to clients o Four “communications pathways” to supplier; that is, how are suppliers made ‘visible’ to clients. n Local variable reference – o Supplier object is declared locally (created temporarily during execution of an operation / method) o Client object declares a local variable within a specific method within client. n Parameter reference – o supplier object is a parameter to, or the return class of an operation in the client object. o A method in client has a formal parameter of type supplier or the method returns an object of type supplier… n (think: File Reader…. These return other objects dealing with I/O… n Global reference – supplier object is global. o Self-explanatory n Field reference – The supplier object is a data member in 35 29 the client object. o There is an instance variable within object of type supplier.

Dependencies vs. Associations: Look at Relationships: What are they going to be/become? o Associations and aggregations is a type of communication pathway that are structural relationships (Visibility = Field Visibility; four slides up). n We’re talking about ‘Association relationships’ realized by variables that exist in the data member section of the class definition. n Field: ALL objects have own copy of instance variables! n Each class stands on it's own. o Dependency is a type of communication pathway that is a more temporary type of relationship – (Visibility = Global, Parameter, & Local; next three slides) n (Parameter – method may/may not be invoked; Local? Temporary n life for execution of method; Global– life apart from object…) Any relationships not associations are dependency 35 30

Local Variable Visibility Dependency o The op 1() operation contains a local variable (an object) of type Class. B (local variable is not a parameter) o Hence there is a dependency between these two classes. Class. A boolean op 1(…. ) // method in Class. A { Class. B my. Class. B = new Class. B (…) op 1 () // note that this is indeed local! … Class. B 35 31

Parameter Visibility Dependency o The Class. B instance is passed to the Class. A instance – hence a dependency. Class. A op 1 (param 1: Class. B) Class. B Format: object name; Class e. g. op 1(my. Class. B: Class. B) If op 1 is invoked, it is passed an object of type Class. B 35 32

Global Visibility Dependency o The Class. Utility instance is visible because it is global. Clear dependency. o op 1() uses something in a Class. Utility object. Class. A op 1 () Class. Utility utility. Op () 35 33

Field Visibility Association o The Class. B instance is visible. There is an ‘association. ’ o Not temporary; Every instance of Class. A has an object of Class. B Class. A Class. B my. Class. B; op 1 () instance variable Class. B utility. Op () 35 34

Example: Define Dependencies (before looking for dependecies) (VOPC Register for Courses Use Case) Up to here, most relationships have been associations and aggregations. (Analysis)( Now, will see how some of these are refined into dependencies. (design) Much was done during analysis! <<Interface>> ICourse. Catalog. System (from External System Interfaces) + get. Course. Offerings(for. Semester : Semester) : Course. Offering. List 1 0. . * <<control>> Registration. Controller (from Registration) course. Catalog current. Schedule The dependency + // submit schedule() 0. . 1 shown (next slide) + // save schedule() + // create schedule with offerings() was previously + // get. Course. Offerings(for. Semester) : Course. Offering. List defined in the Define 0. . 1 Ops section to support 1 the Schedule operation registrant 0. . 1 signatures. All associations /aggregations should be examined to see if they are dependencies. - name - address - Student. ID : int <<entity>> Student (from University Artifacts) + add. Schedule(the. Schedule : Schedule, for. Semester : Semester) + get. Schedule(for. Semester : Semester) : Schedule + has. Prerequisites(for. Course. Offering : Course. Offering) : boolean # passed(the. Course. Offering : Course. Offering) : boolean 35 <<entity>> Schedule (from University Artifacts) - semester 0. . 1+ submit() + // save() # any conflicts? () + // create with offerings() 0. . * alternate. Courses primary. Courses 0. . 2 0. . 4 <<entity>> Course. Offering (from University Artifacts) - number : String = "100" - start. Time : Time - end. Time : Time - days : Enum + add. Student(student. Schedule : Schedule) + remove. Student(student. Schedule : Schedule) + new() + set. Data() 35

Example: Define Dependencies (after 1 of 2) 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. <<Interface>> These instances need to be accessed by ICourse. Catalog. System more than one of the Registration Controller’s, (from External System Interfaces) operations so Field Visibility is chosen + get. Course. Offerings(for. Semester : Semester) : Course. Offering. List from Registration Controller Global visibility to Student and from Registration Controller <<entity>> <<control>> Schedule to Schedule. Registration. Controller (from University Artifacts) (from Registration) Thus relationships current. Schedule - semester remain + // submit schedule() 0. . 1+ submit() 0. . 1 + // save schedule() associations. + // save() + // create schedule with offerings() # any conflicts? () (more ‘permanent’) + // get. Course. Offerings(for. Semester) : Course. Offering. List Field + // create with offerings() 0. . * 0. . 1 A Student manages his/her own Schedules, so Field visibility is chosen from Student to Schedule – and relation remains aggregation. Again, more ‘permanent. ’ registrant - name - address - Student. ID : int Field visibility 1 0. . 1 <<entity>> Student (from University Artifacts) see Schedule as parameter below + add. Schedule(the. Schedule : Schedule, for. Semester : Semester) + get. Schedule(for. Semester : Semester) : Schedule + has. Prerequisites(for. Course. Offering : Course. Offering) : boolean # passed(the. Course. Offering : Course. Offering) : boolean 35 More 0. . * alternate. Courses 0. . 2 0. . * primary. Courses 0. . 4 <<entity>> Course. Offering (from University Artifacts) - number : String = "100" - start. Time : Time - end. Time : Time - days : Enum + add. Student(student. Schedule : Schedule) + remove. Student(student. Schedule : Schedule) + new() + set. Data() 36 Parameter visibility see Course Offering in Student as parameter

Example: Define Dependencies (after; more explanation) Course Offerings are part of semantics of what defines a Schedule (courses Student has selected). Thus Field visibility is chosen from Schedule to Course. Offering; relationships remain associations. The Student class has several operations where Course. Offering appears in the parameter list. Thus, Parameter visibility is chosen from Student to Global visibility Course. Offering. <<Interface>> ICourse. Catalog. System (from External System Interfaces) + get. Course. Offerings(for. Semester : Semester) : Course. Offering. List <<entity>> Schedule (from University Artifacts) - semester <<control>> Registration. Controller (from Registration) It is envisioned current. Schedule the course Catalog+ // submit schedule() 0. . 1+ submit() 0. . 1 schedule() System may need ++ //// save + // save() create schedule with offerings() # any conflicts? () to be accessed by + // get. Course. Offerings(for. Semester) : Course. Offering. List Field vis + // create with offerings() 0. . * multiple clients 0. . 1 0. . * in the system, so alternate. Courses Field visibility primary. Courses 1 registrant Global visibility 0. . 2 0. . 4 0. . 1 was chosen – <<entity>> Course. Offering and relationship Student (from University Artifacts) becomes a (from University Artifacts) - number : String = "100" - name - start. Time : Time dependency. - address - end. Time : Time - Student. ID : int - days : Enum + add. Schedule(the. Schedule : Schedule, for. Semester : Semester) + get. Schedule(for. Semester : Semester) : Schedule + has. Prerequisites(for. Course. Offering : Course. Offering) : boolean # passed(the. Course. Offering : Course. Offering) : boolean + add. Student(student. Schedule : Schedule) + remove. Student(student. Schedule : Schedule) + new() + set. Data() 35 37 Parameter visibility