1. Detail (mid-level part) Design: Mid-Level OO Design – Designing Classes Detailed Design starts with Software Architecture Design (SAD) and fill in the details of the architectural components - - - may cause re-work on SAD, too. There is no “fixed” boundary between SAD and Detailed Design - - - it is not strictly sequential & we may iterate back and forth. Detailed Design has 2 levels: –Mid-level (this lecture set) –Low-level (later lecture) Detailed Design may be: –Static: non-execution oriented (mostly this lecture set) –Dynamic: execution oriented (next lecture set)

2. Detailed Design SRS Design Doc. Design Analysis Architectural Design Detail Design Swft Engr. Design Analyzed SRS Detailed Design Process Generate/Improve Detailed Design Alternatives Evaluate Detailed Design Alternatives Select Detailed Resolution Finalize Detailed Design Detailed Design Doc [selected ] [else ] SAD Analyze SRS and SAD

3. Relative “Levels” of Mid-Level to Detailed-Level Design 1.Conceptual Level : –the class or subcomponent should express the “responsibilities” and “attributes” of the subcomponents or Classes 2.Specification Level: –The subcomponent’s or Class’ precise “interface” and associations between/among classes or subcomponents are specified 3.Implementation Level: –The concrete class or subcomponent that “implements” the interface, with instance variables and algorithms for the code, are described

4. Mid-Level Detailed Design The unit of design is at the Compiled Unit or at a Class level: –Properties –Responsibilities –Relationships The mid-level design specifications include (DeSCRIPTR): 1.Decomposed mid-level components 2.States of these components 3.Collaboration among these mid-level components 4.Responsibilities of each of these mid-level components to perform some task or maintain data 5.Interfaces that these mid-level components use to communicate with each other 6.Properties (such as security, reliability, performance) of these components must be specified. 7.Transition of states and state behavior of these components are described 8.Relationships (inheritance, aggregation, composition, etc.) among the components

5. Low-Level Detailed Design In contrast to mid-level, low level detailed design fills in the details for later programming purpose (PAID): 1.Packaging of the code into compilation unit and libraries is decided 2.Algorithms are described in detail steps 3.Implementation issues such as visibility and accessibility of entities and low level relationships among entities are described 4.Data structures and data types are specified

6. Sample: Detailed Design Document Content 1.Mid-Level Design Models (in the form of Class diagrams, sequence diagrams, state transition diagrams, etc.) 2.Low-Level Design Models (specific algorithms, data structures, implementation guidelines for non-functional attributes such as security or performance, packaging) 3.Mapping between Models (showing how the models are related) 4.Description of Design Rationale (describing the design decisions made and factors that contributed to the decision) 5.Glossary of terms and acronyms used very important average importance

7. Static Descriptions (Design) (based on text book & thus OO Biased ) Associations Among Classes –Generalization and inheritance (“is a” relationship) –Interfaces of classes –Aggregation (“part-whole” relationship) & Composition –Adornments for more complex association Classes –More properties about attributes and operations may be specified: With { } to indicate constraint Visibility and Accessibility indicator Class or Instance variables Rest of this lesson lecture notes will focus on the following:

8. Class Generalization/Inheritance & Association Generalization is a “parent-child” or “sub-typing” relation between classes ---- close to the notion of abstraction –e.g. dog “is a” animal Association represents a more general relationships between instances of classes –A person “works” for a company; company “has” a number of buildings fish salmon whale Generalization personcompany Association Works for1-- *0..2

9. Multiple Inheritance fish salmon whale mammal dog breathe( ) move( ) Consider: Whale really “is a” fish at the same time “is a” mammal? Which “move ( )” or breathe( ) operation should be inherited ? size:int breathe( ) move( )

10. Abstract Class for mid-level design In design we May Not fill in all the details of a design. –Abstract class is an example of such a situation. –An Abstract Class is a class that can not be instantiated because it contains a method or operation without the body. It is useful as a parent-class which is inherited by some child- class that has “implemented” the method that has no body. > animal move ( ) {abstract} fishdogbird Each of the sub-classes: - fish - dog - bird will have a different move( ) operation that needs to be “implemented” differently We use abstract class as a design for the purpose of enforcing a certain set of common attributes and operations that must be inherited by all descendants ( You may think of this as a “restricted or controlled” polymorphism ) If we do not use stereotype descriptors, then we must italicize to show abstract class weight: int origin: string

11. Interfaces for mid-level design Interfaces are important in design because it shows the relationship of dependencies (of features - attributes or/and operations) Earlier we have discussed the provided and the required interfaces, along with the “ball” and the “cup” to indicate the provider of the feature versus the dependent of that feature. Here we show another notational approach temperature gauge temperature gauge > temperature UpdateTemp (temp: object) GetTemp ( ): object thermostat Provided interface Required interface temperature gauge thermostat temp: object

12. Further notes on Interface In Java programming, “Interface” contains: –constants and –abstract methods abstract method is just a signature that has no implementation Interfaces in Java programming provides a certain amount of polymorphism through different classes that “implement” the interface Also note that we can use interface to perform “information encapsulation” by making the data only accessible through the interface method.

13. More “Specifications” for Mid-Level design More properties may be “specified” for the attributes and operations using { }, constraint : Department DepName: string {constant} Person: employee Memlist: employee[*] {ordered} addEmpl (person:employee) delEmpl (person:employee) {synchro} Department name is a string constant. Memlist is an ordered list. delEmpl is an operation that must be synchronized. Recall from (p. 202-203 of your textbook): Attribute format - name : type [multiplicity] = initial value Operation format - name (parameter list) : return-type-list

14. “Visibility” Characterization for Mid-Level Design Visibility or accessibility constraints on attributes and operations should be thought of at mid-level design: –Public (+): visible and accessible anywhere by everyone –Package (~): visible and accessible within the package where the class appears –Protected (#): visible and accessible within the class and all its sub-classes –Private (-): visible and accessible only within the class : Department + Name: string {constant} + Memlist: Employee[*] (ordered} # address: string Also, go back to the interface diagram and see if you would make the attribute, temp, to have a “private” designation --why ? visible hidden

15. Class (global) and Instance (local) notions for mid-level -design During mid-level design, we need to specify which attribute and/or operation should be “global” in nature versus “local” in nature. –Class level : one copy and sharable among all instances of the class. (sometimes called “static” variable and is underlined) A constant such as Pi may be a class variable that is shared by all objects –Instance level: a separate copy for each instance of the class (or object) and the value of the copy is specific to only that instance. An employeeName may be an instance variable that is read in by different objects and varies depends on which employee record is read by which object. figure +pi : double {constant}

16. Differentiating “Part-Whole” Relationship Concepts Aggregation is a “part-whole” association. Composition is a “special kind” of aggregation where the part may only belong to one whole at any time. Replenish-list Sold-item list item An item may belong to the replenish-list and may also be on the sold-item list. Is the aggregation symbol 1… * kitchen house subdivision A kitchen belongs to only one house, which in-turn sits in only one subdivision. is the composition symbol. following has always been a tough distinction to remember:

17. Transitivity Property Note that some relationship may look like an aggregation, but not. Aggregation should be transitive. 1. Person Z is biologically-related to father y; father y is biologically related to family x. The person Z is biologically related to the family x. (this is a transitive relationship --- thus an aggregation) 2. Joe is a member of a church y; church y is a member of entities that don’t pay taxes. Is Joe a member of entities that don’t pay taxes? --- but Joe may pay tax! (be careful with is “a member of” versus “possess the characteristics” of )

18. Complex Association Sometimes association itself may be complex and needs a class, which has attributes and operations pertinent to the association. –We can use an Association Class to provide the information pertinent to the association that does not belong to either of the associated objects. Itemscustomer Sales date Item-list sales-person Further describes the sold-to association >

19. More adornments for association Qualifiers : one or more association attributes, which together with an instance of the qualified class, picks out the instances of the other class that participate in the association. Navigability: indicates if an instance of a class can access (one way or two ways) an instance of the associated class. Visibility: indicates the attribute that is used for accessing (association) between the two instances of classes is public, private or protected.

20. Association Qualification adornment Univ. Directories Student student name student id# 0..1 0..* 1.Note that given a university directory, with the qualifier of student name and id#, there is either such a student or none 2Given a student there may be no entry in any of the university directories (error) or one or more entries in different university directories

21. Association Navigation &Visibility adornments StudentClass X Navigation of student accesses classes, but not vise versa Building 0..* 1 + class_id + building_id Navigation of Class and Building are bi-directional and are done through accessing the public attribute class_id and building_id are publicly visible

22. “Coming Up with” or Drafting the Mid-Level Design This discussion is primarily OO-based; thus the aim is to come up with mid-level design of classes –Creational technique : Decomposition/Composition based on functionality, “quality” (non-functional) attributes, or both (just as we did for High Level Design) –Transformational technique: Converting the conceptual (problem) model to a draft design model (much as what was done with High Level Design) Requires a good SRS and SAD or Transforming a previously completed, similar design For experienced people, they usually have some previous, similar design in their brain and would draw upon that first--- and then create more

23. Creational Technique 1.Generate a Design Story (based on what you think are the most important aspects of the solution); list the key “themes” in the story. 2.Use the themes and “brainstorm.” For each theme identify and list: Entities in charge or involved in the theme Things that interact with the solution part of theme Things whose data needs to be stored Any structure or collections of entities 3.From the list in step 2, generate “candidate” classes. List their names List their responsibilities 4.Evaluate the list of classes: Discard those that seem to be unclear in name or responsibilities Rework those classes that have overlapping responsibilities Discard those that seem to be “out of scope” 5.Draft an initial Class diagram showing Classes, each with attributes and operations Associations among classes 6.Check the Class Diagram: Check each class for missing/inaccurate attributes and operations Combine common attributes and operations into a super-class, if necessary Look for “required’ and “provided” components (using design patterns) Generating Classes from Themes Developing a list of classes and the class diagram Review and improve the class diagram

24. Transformational Technique 1.Start with the conceptual model (requirements and high level design) and convert the actors in the conceptual model to interface classes. 2.Add data collection classes for all those actors whose data needs to be recorded 3.Add a start-up class to start the execution of the solution. 4.Convert controllers and coordinators in the conceptual model into classes and add any that needs to be included as control and coordination classes. 5.Data types with complex structure in the conceptual model needs to be converted to classes 6.Decide on whether container classes (abstract data structure) are needed, include them if necessary 7.Add Associations and interfaces; draft the class diagram

25. Some Static Modeling Heuristics for mid-level design 1.Responsibility driven decomposition 2.Inheritance 3.Delegation

26. Responsibilities Driven Decomposition Responsibility (functionality) is an obligation to: –Perform a task (operational responsibility) –Maintain some data and non-functional information (data responsibility) Responsibility driven decomposition –Generating lower level operational responsibility components based on decomposing the high-level operational responsibilities –Generating lower level data responsibility components based on decomposing the high-level data responsibilities. Responsibility and design principles (cohesion and coupling): –Assign a module (class) with at most one operational responsibility and one data responsibility - - - cohesion ----practical ? –Assign complementary data and operational responsibilities together- - - cohesion –Make sure module responsibilities do not overlap - - - cohesion and coupling –Do not place extra operational and data elements into a module - - - cohesion and coupling –Make sure that all needed operational and data elements are included in the module to fulfill the responsibilities - - - cohesion and coupling

27. Starting a Design (used for discussion of “inheritance” and “delegation” --- later) Consider designing a component dealing with a bank account. A bank account handles the deposit and withdrawal of that account. Each bank account is owned by one to three people. Information about a bank account such as owner, open date, account type must be kept and maintained. Note: What should we do with account information such as account type or owner ? Account amt : real total_amt:real act_num: int Deposit (amt :real, act:int ) Wdraw (amt :real, act :int)

28. Capture the Ownership Information & Relationship Account amt : real total_amt:real act_num: int Deposit (amt : real, act:int ) Wdraw (amt : real, act ;int) Owner_Info addr : string Tel : int ss_num: int B-date: date Act_num : int. setaddr ( ) getaddr ( ). * 1..3 Account_info

29. Discussion on Cohesion and Coupling Consider designing a component dealing with bank account and account information Account amt : real total_amt:real a_num: int deposit(amt : real, a_num:int ) wdraw (amt : real, a_num ;int) Account_Info owner: string co-owner: string act_type:integer act_st_date: date act_num: int getOwner (act_num: int) string setOwner (act_num:int, owner:string). Should these be combined as one Class or left separately? (cohesion and coupling trade-off ?) 0..11

30. More Discussion on Cohesion and Coupling (cont.) How should these Classes be combined, if at all? Account amt : real total_amt:real a_num: int deposit(amt : real, a_num:int ) wdraw (amt : real, a_num ;int) Account_Info owner_name: string act_type: int act_st_date: date act_num: int getOwner (act_num: int) string setOwner (act_num:int, owner:string). Should these be somehow combined or left separately? (cohesion and coupling trade-off ? – and db performance ?) Owner_Info name: string addr : string tel : int ss_num: int b-date: date. setaddr ( ) getaddr ( ).

31. Inheritance Remember: –Inheritance is a generalization relationship between a super-class and its sub-classes. –Inheritance provides a mechanism for re-use in mid-level designs. 1. Combine common attributes and operations in similar classes into a super-class 2. Use inheritance only when there is a generalization relationship between the super-class and its sub-classes.

32. Generalized Account_Info (from earlier example) for Inheritance? Instead of act_type attribute in the Account_Info Class to differentiate the different accounts, should we have designed a “generalized” Account_Info class and have each account type inherit from the generalized class: –Personal checking account with all kinds of rules such as free checking for 6 months, overdraft fee, etc. –Personal money market account with no minimum deposit, but gives only regular interest –Personal money market account with minimum of $50,000 deposit gets regular interest plus.25% more. –Small Business account.

33. Delegation Delegation is a mechanism to decompose the responsibilities and assign some of the responsibilities to different classes. This allows classes to re-use a class that has been given a set of responsibilities that is needed by other classes. So ---- based on delegation, should we keep Account and Account_Info separately ?