Class Design Phases

Where Are We? We’ve done our Product Design resulting in –Use Cases/Use Case diagrams –Class diagrams (initial) –State diagrams –Deployment diagram

Where Are We? (cont.) We’ve also produced –Object Persistence specifications –Process Architecture –Human-Computer Interface specifications What’s next? –Class Design (internals)

The Deliverables of the Class Design Process Class diagrams are further refined in this phase of development Object diagrams are created Interaction diagrams are created Class skeletons are created to embody all analysis and design information created to this point in the development process

Relationships of SE Phases and UML Diagrams Analysis Use CasesScenariosClass Diagrams Class Design Object Diagrams Interaction Diagrams Class Diagrams Class Skeletons Implementation Class Definitions

Relationships of SE Phases and UML Diagrams Analysis Use CasesScenariosClass Diagrams Class Design Object Diagrams Interaction Diagrams Class Diagrams Class Skeletons Implementation Class Definitions

Class Skeletons We will preview class skeletons to better understand the objectives of design Class skeletons are partial class definitions Class skeletons should be heavily commented, so that the purpose of all attributes, methods, and constructors is clear Class skeletons are the basis for the implementation phase of development

Contents of Class Skeletons A list of the roles the class plays within the system Information concerning when objects of the class are created and deleted (information maintenance) For each role, the semantics of the class All attributes with access modifiers, types, names, and semantics For all constructors and methods, their signature, semantics, preconditions and postconditions

LMS Class Skeleton public class Patron { // Class Semantics and roles // Library Patrons function in two primary // roles, as researchers who use index, // reference and database materials, and as // borrowers of loanable resources. // Information maintenance // Creation: new patrons are introduced // into the system by library staff when // presented with a library membership // application or from information // retrieved from a web-based application

More LMS Class Skeleton // Information maintenance continued // Deletion: patrons are removed from the // library database 3 years after their // membership expires // // Instance variables private String name; // Patron name in // last, first, middle initial format private long PatronID; // Patron library ID // number. Automatically generated...( See deliverable 5.1 for other instance variables )

More LMS Class Skeleton // Class variables private static long nextPatronID; // Keeps // track of next patronID to be assigned // Constructors public Patron(String n, long home, Date m, Date e, String street, String city, String state, long zip) { // Parameters: n = name, home = homephone // PatronID = getnextPatronID() // street,city, state, and zip are used // to create an address object for // homeAddress

More LMS Class Skeleton // Constructors continued // Precondition: for constructor: // Library database can accept an // additional entry and memory allocation // succeeds // Postcondition: Library database will // contain an additional Patron and Address // entry } // Static methods public static long getnextPatronID() { return nextPatronID; nextPatronID++;}

More LMS Class Skeleton // Non-static methods public boolean validatePatron(Date e) { // ensure membership is not expired // Precondition: expireDate != null // if expireDate <= Today return false // else return true }...( See deliverable 5.1 for other non-static methods ) } // end class Patron

System Decomposition Convert general/abstract models created during the analysis phase into detailed models Stepwise refinement/evolutionary development Leads directly to the system implementation

Class Design Expand on the analysis deliverables to ensure complete functionality coverage –We’re about to commit ourselves so we want to make sure the design is complete and correct Add detail to class diagrams –Attributes –Method signatures Produce a class skeleton which will eventually turn into code

Class Diagrams Revisited Portray the elements of a class and the relationships between classes –Class –Interface –Relationship –Collaborations

Class Diagrams (cont.) Class –May be just a class name –May include attributes and/or access methods class-name attribute1 attribute2 method1() method2(int) method3()

Class Diagrams (cont.) Relationships (between classes) –Association –Generalization –Dependency class-1class-2 does-something-to base-classderived-class change-mechange-me too

Class Diagrams (cont.) Interface –Class interactions –Enforces encapsulation –Generally left out until the design phase class-1class-2 interface-1

Class Diagrams (cont.) Collaboration –Specifies that multiple elements must interact to produce a given behavior class-1 class-2 interface-1 class-3 update-operation

Class Diagrams (cont.) Access modifiers –Specify the mode of access of class methods and attributes Public Private Protected class-name -privateatt0 -privateatt1 +public0() -private0(int) #protected0()

Class Diagrams (cont.) Multiplicity –Cardinality of an association relationship PatronResouce *

Class Diagrams (cont.) Role –Descriptive label about the part an object plays in the association PatronResouce * Borrower

Class Diagrams (cont.) Constraints Tagged values –Special circumstances that must be considered –Versioning of diagrams –Associations with functional requirements –Nonstandard information PatronResource * Borrower {Requirement #5} {Student at most 25 resources} {Faculty and staff – no limit}

Class Diagrams (cont.) Aggregation –Class containment –Filled diamond means the contained class cannot exist on its own –Hollow diamond means the contained class can exist on its own Address Patron Overdue Notice Resource Name

Aggregation Often represented as an association Often represented by inclusion of an object type (class) in the attribute field of the including class All techniques are acceptable –Just make sure your designs are clear and concise

Interaction Diagrams Specify the interactions between classes –This information is absent in the Class Diagrams (only show relationships) –Collaboration Diagrams Structure of interactions –Sequence Diagrams Time ordering of interactions (messages)

Interaction Diagrams (cont.) Consists of –Objects Instance of a class (not the class itself) Links/Messages –Association between instances –Corresponds to an association in the Class Diagram –Likely to be implemented as a method (function) call

Interaction Diagrams (cont.) Loosely speaking Use Case Scenario instance of Class Diagram Interaction Diagram instance of –Analysis phase –Design phase –You’ll have one for each scenario

Interaction Diagrams (cont.) Object-name : class method-name(params) Object Link Message Symbols

Collaboration Diagram Also known as a Communication diagram (UML 2.0) Describe the Structure of interactions between classes

Steps for Creating Collaboration Diagrams Identify a behavior to model Identify participating class and their relevant interrelationships Identify a specific scenario to model determine necessary message passing to carry out the behavior Introduce solution for object persistence, if needed

Collaboration Diagram :Life :Grid :User Interface CreateGrid(rows, columns) GetSizes(rows, columns) :Cell CreateCell() DrawGrid() EnterSize(rows) EnterSize(columns) User Initiate Game Scenario {Requirement #2}

Collaboration Diagram (cont.) :Grid :User Interface :Cell SetColor(bool occ) DrawGrid() UpdateCell(row, col) Set Cells Scenario User LBCallback(row, col)

Collaboration Diagram (cont.) :Grid :User Interface :Cell UpdateCell() :Ruleset UpdateCell(row, col) DrawGrid() Run Rules Scenario User StartCallback() ApplyRules() :Timer Start()

Collaboration Diagram (cont.) Just another step in the evolution of the system –Class Diagrams outline the general associations –Scenarios provide detailed “stories” –Combining the two provides us with clues to needed classes/methods/attributes/interfaces

Collaboration Diagram (cont.) Development of collaboration diagrams is an art, not a science –Basically, you’re writing programs, you’re just doing it pictorially and at a level a step or two above actual “programming” It all starts with the Use Cases and Scenarios and proceeds by adding detail to the Class Diagrams

LMS Case Study: Collaboration Diagram(Partial) : Patron : Library System : LibraryDatabase Checkout(ResourceI D) validatePatron(MemDat e) ( See deliverable 5.3 for entire diagram ) update(Patron ) create(LibraryDatabas e) getResource(Resource ID) getPatron(PatronID)

Sequence Diagram Describe the timing or ordering of interactions (messages) between classes

Sequence Diagram :Life:User Interface GetSizes(rows, columns) :Grid CreateGrid(rows, columns) :Cell CreateCell() DrawGrid() Initiate Game Scenario {Requirement #2} {Continue only when the rows/columns are less than 100}

Sequence Diagram (cont.) Similar content to Collaboration Diagrams Add the notion of “time” –Time increases from top to bottom –Topmost objects/messages are created/sent first –Objects may come and go over the life of the system Again, it’s an art, not a science

Sequence Diagrams Like collaboration diagrams, sequence diagrams model dynamic aspects of the system by specifying the interaction among objects to produce a particular behavior Sequence diagrams specify the time ordering of messages Sequence diagrams show the life span of each object

LMS Case Study: Sequence Diagram(Partial) : Patron : Library System : LibraryDatabase create(LibraryDatabas e) getResource(ResourceID) getPatron(PatronID) validatePatron (MemDate) (See deliverable 5.5 for entire diagram )

Object Diagrams Models a set of objects and their interrelationships during a system snapshot A system snapshot is the state of the software system at a selected moment of time Object diagrams model another static perspective of the system Unlike other diagrams, object diagrams may contain multiple instances of the same class

Steps for Creating Object Diagrams Identify a system snapshot within a scenario to model Identify participating classes and their interrelationships Identify all allocated objects at the time of the snapshot Show the state of each object in the snapshot Determine all interobject links

Object Diagram :Life :Grid rows = 12 Cols = 16 :Cell (0,0) occupied :Cell (0,1) occupied :Cell (11,15) unoccupied

LMS Case Study: Object Diagram (partial) currentP: Student : List name=“Gert Stein” libraryID= homephone= workphone= membership= expire= :Book name = “SOTY” author=“b. hooks” ISBN=... :Book name = “FOF” author=“Ehrenreic h” ISBN=... (See deliverable 5.7 for entire diagram )

Why All The Diagrams? Code reuse –Identify reusable classes (inheritance/aggregate) Well-designed classes and methods –Private attributes (data) –Proper initialization (constructor) –Abstract data types (aggregates) –Self-documenting (attribute/method names) Assurance of data integrity –Object updates (interrelated transactions)

Code Reuse Collaboration diagrams are of particular use in pattern scavenging Pattern scavenging involves studying the various diagrams produced during analysis and class design to identify patterns of class interaction Once such patterns are found, they should be evaluated to determine if they can be effectively reused

Reuse in LMS Resourc e Checkabl e Resource Reserve Resourc e BookElectroni c Media

Evaluating Design Modeling software helps us produce correct, well- structured systems The resultant models can also be scrutinized for potential data integrity problems For example, in the LMS system, having update methods execute separately for the Patron and Resource objects may result in data integrity errors if system failure occurs between the initiation of the first method and the termination of the second method

Guidelines for Class Design Always keep data private Always initialize data in a constructor Do not use too many related primitives Not all attributes need individual accessor or mutator methods Order elements comprising class definitions consistently Break up overly complex classes into multiple classes Name classes, methods and attributes well

Verification of the Class Design All system requirements developed during analysis must be addressed during design –All design documents must cross reference requirements from the requirements specification All required attributes and methods must be used properly –E.g. data integrity of attributes must be enforced by update methods The modules comprising the system must work together properly

Why All The Diagrams? (cont.) IT’S EASIER TO CHANGE THESE DIAGRAMS THAN IT IS TO CHANGE CODE! IT’S EASIER TO DEBUG WELL WRITTEN CODE THAN POORLY WRITTEN CODE!