Unit 2 : Problem Solving Through Object

1. Unit 2 : Problem Solving Through Object Content • Software development cycle • What are objects? • Deriving objects from a given problem • Generalization / Specialization • Case Studies • Appendix : a Diagram with different Names ?

2. A) SDLC - Software Development Life Cycle pp-3 • well-defined steps to handle & manage development • it avoids : • problems in coordinatingmany developers & many programs on a large project • miscommunication between developers & users • SDC is cyclical, not linear • also called 'waterfall model'

3. Simplified SDC model Requirement Phase It’s also called a WaterFall Model Analysis Phase Design Phase Implementation Phase Testing Phase Maintenance

4. According to nature of common activities in s/w development, it is divided into 6 phases: Requirements phase Analysis phase Design phase Implementation phase Testing phase Maintenance phase Simple software : a single pass may suffice Sophisticated software might be too complicatedto build with a single pass through these 6 phases. A single pass might only complete a portion of the features (or a software module) of the system.

5. An Iterative approach Requirement Phase Analysis Phase Design Phase Implementation Phase Testing Phase Requirement Phase Analysis Phase Design Phase Implementation Phase Testing Phase … … … Requirement Phase Analysis Phase Design Phase Implementation Phase Testing Phase Maintenance

6. An Iterative approach • the entire software development is divided into iterations. • Each iteration aimed at a portion of the system and each iteration takes all except Maintenancephase • iterates, cycle-by-cycle until system tested OK, moving to MaintenancePhase • no. of cycles varies as • system complexity & • developers’ decision • eg. • it finished in 5 cycles • with a spiral view

7. Pipelining • Example : while some developers are working on the testing phase of an iteration, another group of developers has already started working on the requirement phase for the next iteration.  • complete more projects in shorter time Project -A Requirement Phase Analysis Phase Design Phase Implementation Phase Testing Phase Project -B Requirement Phase Analysis Phase Design Phase Implementation Phase Testing Phase Time

8. A Completed SDC Diagram pp-9 • When expected output of a phase does not meet the users’ requirements, either • back to its prior phase ( 1 step back ), or • back to earlier phases ( some steps back ) • eg. In Implementation, when some info is missing : • Programmer ask a Designer, who may go back to the Design Phase & re-design the system, or • the Designer ask an Analyst, who may go back to Analysis Phase & clarify user requirements • After clarifying the info, resume normal process • So, a complete SDC model must allow going back to 1 or more phase(s) when necessary

9. Requirement Phase meet needs Analysis Phase N Y Normal process flow meet needs Design Phase Y N meet needs Implementation Phase Y N meet needs Testing Phase Something wrong ? Go back to appropriate phase(s) Y N meet needs Maintenance Y N

10. OO approach to Software Development • s/w developers try to modelreal-world scenarios & system operations by objects. • relationship between classes & objects • a class definition is defined for • objects with same type, and • entities with same attributes & behaviors • When an application is executed, the relevant class definitions are used to create objects so that the objects have the appropriate attributes and behaviors. • so a class is a blueprint for a group of objects of the same category, eg. • made cookies(object) from CookieCutter(Class)

11. 1) Requirements phase (SDC Activities) Objectives • collect requirements (needs) from user/client who request for software (s/w) development. • “needs” refer to functionalities of the software, • Requirements may include software limitations • sample requirements of a payroll system • what types of staff are to be supported, • what types of payment method are required, etc. • limitations are constraints of the software, such as hardware, time limits & budget. • eg. users may require a response time < 3 sec, • finish the s/w on Linux platform, in 3 months without exceeding a budget of HK$ 20,000

12. Activity • interview the • client, who requested the s/w, and • end user, who’ll use the s/w • Common problem is miscommunication between client/user & developer because : • users use business terminology (jargon), & • developer have little business knowledge. • From time to time, developers seek users’ clarification Deliverables • developer prepare a problem statement, which summarizes all user requirements, including software limitations • a problem statement help user & developer clarify the needs & limitations early in s/w development.

13. 2) Analysis phase Objectives • to understand operational details for each user requirement • focus onwhat a system must do Activity • to identify functionalities & features of the software based on the problem statement from requirements phase

14. Deliverable • produce requirement specifications • list of roles of the users of the software • eg, in banking, users are customer, teller, supervisor & manager • list of functionalities or operations for each role • eg, in a banking, account operations are deposit, withdraw & transfer. • allow Teller to perform all these operations, but • only Supervisors can modify transactions made by tellers. • list of operationalscenarios under different conditions • allow withdraw operation, if account has enough money • else, reject the withdraw operation & the s/w alerts user • list of businessentities with their attributes & behaviors • a transfer operation involves 2 accounts + a transaction record. • account has an attribute, 'balance', and 2 operations, deposit & withdraw

15. Remarks • these 2 phases (requirement & analysis) are programming language independent because • their Objectives is to collect user requirements & • to understand the operational details. • If not enough information was collected, repeat the requirement phase • until thoroughly clear about • what the users expect and • the details of all functionalities

16. 3) Design phase Previously, developers analysis a system in business viewpoint Objectives • transform requirements into technical design • model real-world cases & system operations by objects • Design class definitions (re-use in implementation phase) Activity • From requirement specification, find attributes of objects • Objects of the same type, and entities with same behaviors & attributes, are defined as a single class. • consolidate Operational scenarios to well-defined steps of behavior Deliverable • List of classes, each with a list of attributes and behaviors (with well-defined steps ) is produced

17. 4) Implementation phase Objectives • aims at converting the class designs derived in the design phase to actual class definitions in the chosen programming language. Activity • use Java (in our course) to implement • the classes, their attributes and behaviors Deliverable • method bodies • program codes which are ready for testing

18. 5) Testing phase Objectives • to make sure the programs do what we expected • uncover software errors before releasing it to users Activity • verify programs by • feed in test data and then • check if outputsmatchexpected results. • If un-matching, codes are examined & checked for errors • After errors are found / corrected, programs are re-tested • This process is repeated until all errors are corrected Deliverable • a readily deployable software system

19. 6) Maintenance phase pp-9 Objectives • to fix the errors found after deployment • in large & sophisticated system, not all errors can be found / corrected at testing phase • in adapting to a rapidly changing world, software need to be enhanced / enriched for users to continue using Activity • involves code modification, which may take much effort for improperly designed/implemented software • maintenance cost will > the sum of prior 5 phases. • That’s why we need a systematic way to build software Deliverable • an updated software with fixed errors & enhanced feature

20. B) What are objects ? pp-10 • Real-World Objects (RWO) • Our world is made up of objects • a chair, a television set, a computer • everything are objects. • desktop/personal computer (PC) & notebook computer are in the same category “Computer“ • they are characterized by attributes such as • hard disk & RAM size, CPU type/speed • In OO, we call such a category a class. So, PCs are instances (or objects) of the class “Computer“

21. Software objects (SO) • OO software use SO to model RWO, both physical things and abstract concepts or ideas. • SO has attributes to mimic characteristics of RWO • SO has behaviors that correspond to the actions of RWO • RWO may have many characteristics & actions • SO model only a subset of them for a specific problem. Thus, the same RWO may be modeled differentlyin different software. • SO only exist while a s/w is running. The object states must be stored properly so that they can be recreated the next timewhen the software is run.

22. Object concepts attributes vs. states • attributes = properties of an object • states = values of properties of an object • which reflect current situation of the object • objects always have attributes, and • their values (or states) may change over time, especially if they are manipulated in any ways • the value of an attribute determines the current state of an object

23. message vs. behaviour • in a software system, an object will never perform its behavior unless we send a message to it • message type & object behavior is 1→1 mapping • If an object has a behavior such as ‘doSomething ’, it is expected that it can • accept a message type ‘doSomething ’ and • perform the ‘doSomething ’ behaviour.

24. Class Name Attributes Behaviors Class Diagram for a Washing Machine • Attributes & behaviors of a washing machine object are identified in analysis phase. • In design phase, a class definition is used to describe / model a washing machine object • divided into three regions - • class name • attributes • that each object of this class has • behaviors • that each object of this class has

25. object name is wM An anonymous object (object name is optional) Class Name Data Types Attributes wM : WashingMachine WashingMachine :WashingMachine brandName = “ABC” modelNumber = “WM-201” capacity = 5 timeRequired = 45 consumptionRate = 50 height = 880 width = 530 depth = 530 brandName : String modelNumber : String capacity : double timeRequired : double consumptionRate: double height : double width : double depth : double brandName = “ABC” modelNumber = “XYZ” capacity = 5 timeRequired = 45 consumptionRate = 50 height = 880 width = 530 depth = 530 start ( ) top ( ) setTimer ( hour : int ) getTimeElapsed ( ) : int start ( ) top ( ) setTimer ( hour : int ) getTimeElapsed ( ) : int start ( ) top ( ) setTimer ( hour : int ) getTimeElapsed( ) : int Class definition Object instances Behaviors ': int' indicates the returns feedback of type integer

26. The Given Requirements pp-15 • 'Start Washing' button of washing machine is pressed • The incoming water valve is opened for 5 minutes.  • The drum motor starts at normal speed for 15 minutes.  • The outgoing water valve is opened.  • The drum motor starts at high speed for 5 minutes.  • The outgoing water valve is closed.  • The incoming water valve is opened for 5 minutes.  • The drum motor starts at normal speed for 15 minutes.  • The outgoing water valve is opened.  • The drum motor starts at high speed for 5 minutes.  • The outgoing water valve is closed.

27. Accomplishing tasks by objects • In OO programming, tasks always involve objects. • To complete a task, we expect • some results will be returned from the objects or • the states of some objects will be changed. • Suppose the objects WashingMachine, DrumMotor, IncomingValve and OutgoingValve have been found to be appropriate. • The washing operation can be accomplished by messages sent among the objects.

28. pp-16 1 : wash ( ) :WashingMachine 3, 8 : startNormalSpeed (15) 5, 10 : startNormalSpeed ( 5) 2, 7 : open (5) 4, 9 : open ( ) 6, 11 : close ( ) :IncomingValve :OutgoingValve :DrumMotor Modeling the washing Machine Objects

29. Interaction among objects pp-17~8 • behaviors of an object are not performed unless it receives a message • the only interaction among objects is the messages sent among them • While sending a message from Sender to Receiver, the Sender assume that the Receiver can : • understandthis message & • perform a behavior according to this message • Sender concerns What the Receiver will do • Sender doesn’t concern How a Receiver works • Receiver can determine its own way to perform a behavior according to this message

30. Benefit of such interaction among objects • capability of handling complexity • every object (the agent) is only required to perform its own operations based on the attributes and the supplementary data in the messages (parameters) when it receives particular messages. • Each object performs its own part. • All objects cooperate, and they constitute a complex operation. • It is much easier for analysts to : • clarify a single operation of an object than • analysis all scenarios when many objects are involved in a complex operation.

31. C) Deriving objects from a given problem • core activity in analysis phase • identify object/class and their attributes & behaviors from the problem statement • more than 1 result may be derived, it depends on our understanding on the problem and our trade-offs • eg. pp-29, methods can be defined in 2 ways. • there is no fixed rule to select the best way • Regardless of the derived result, make sure that • the derived objects can fully model all scenarios.

32. Textual Analysis • Given a problem statement • find objects by highlighting (or underlining) the nouns and noun phrases • the steps are: • Determine the involved objects (and the classes) • Determine the object attributes • Determine the object behaviors • Verify if the list of objects & behaviors is complete or not The bank system transfers an amount of money from a source account to a destination account. It first withdraws the amount from the source account and then deposits the same amount in the destination account. The bank system transfers an amount of money from a source account to a destination account. It first withdraws the amount from the source account and then deposits the same amount in the destination account.

33. Noun Candidate Object / Class an Entity ? Y N relevant ? Y Object Attributes N Discard it Step 1 & 2: Identify Object/Class & Attributes • nouns (& noun phases) can be : • objects / Class or • object attributes or. • duplicated (already identified) object, or • irrelevant to our model. • determination criteria : • if we interest in modeling the thing itself, then model it as separate class • for things that we are not interested but are helpful properties of some classes, then treat them as attributes

34. The decision to consider whether it is necessary to model an object by class definition is based on our understanding of the problem, so there is no concrete answer.  • group the nouns of the same type of entity and • give it a class name • After grouping&filteringthe nouns & noun phrases, we have a list of • class names • Don’t use plural nouns. ( No “s” ) • all CamelStyle (capitalize 1st letter of each word) • and their attributes • start with lowercase letter & • use CamelStyle to concatenate the rest

35. Finally, determine whether an object comprises other identified objects or an object has other objects as its components CPU = CU + ALU + Reg ( ref : Von Neumann arch.) if an object has attribute for each component object, then give a name to each one.  if an object always sends messages to some objects, then the corresponding class definition has an attribute for each of them. WashingMachine has attributes (components) of IncomingValve, OutgoingValve and DrumMotor

36. Step 3: Identify Object Behaviors • generate a list of potential object behaviors by identifying verbs & verb phases in the problem statement • if 2 different verbs are referring to the same behavior, • then choose any one of them.  • check which object(& class) has these behaviors • eg. state changes or action taken • some verbs only specify that • an object has attributes (rather than behavior) • the output in this step is a list of object behaviors that we can add to the related classes.

37. Step 4 : check completeness of objects & behaviors • Analysis the scenarios when messages are sending among objects. Verify/check whether : • object behaviors suffice to model the scenarios, & • supplementary info is needed to perform the behavior • Is the list of objects & behaviors ( it) complete ? • if we can model the original scenario based on a sequence of object behaviors, • then it is complete • this also marks the end of the analysis phase • if itcannot cooperate to finish a task, • then it may be incomplete • we have to re-analysis the problem & reviewit. 

38. eg. transfer $ between accounts (Analysis Phase) • highlighting / underlining nouns & noun phrases • Build table • check entries in 1st column, for candidate Classes, • if yes give a class name in 2nd column 'Class name' • else write comments on 3rd column The bank system transfers an amount of money from a source account to a destination account. It first withdraws the amount from the source account and then deposits the same amount in the destination account. not an Entity but still useful copy all nounsfrom the requirement statement all CamelStyle both SRC & DES are accounts, so Group them as BankAccount Class

39. The bank systemtransfers an amount of money from a source account to a destination account. It first withdraws the amount from the sourceaccount and then deposits the same amount in the destination account. • highlight Verb & Verb Phases • To draw our diagram • use the 2nd column of our table, draw all Classes • draw arrows according to our highlighted behaviors • label all arrows with the name of the behaviors • label all arrows with their operational sequence • filling supplementary data / parameters source:BankAccount 2 : withdraw (amount) :Bank 3 : deposit (amount) 1 : transfer (source, destination, amount ) destination:BankAccount

40. BankAccount Bank balance : double withdraw ( amount : double) deposit ( amount : double) transfer ( source : BankAccount , destination : BankAccount , amount : double ) eg. transfer $ between accounts (Design Phase) • a bank account should maintain its own balance • So, an attribute balance is added to it. • to facilitate Java implementation we have to consider some language-specific issues, like data type. • Thus, double, which can keep real numbers, is chosen for the attribute balance & all the related behaviors. • the resulted class definitions:

41. Staff name: String staffNumber : String calculateSalary( ) salary : double D) Generalization & Specialization (gen-spec) • Given 3 similar classes differ by name only • By generalization (a new class Staff is created) • gen-spec are 2 sides of the same coin Clerk Manager Director name : String staffNumber : String name : String staffNumber : String name : String staffNumber : String calculateSalary( ) salary : double calculateSalary( ) salary : double calculateSalary( ) salary : double specialized by some specific attributes / behaviors • eg. commission • generalizing common attributes / behaviors • eg. name super class subclass Clerk Manager Director otPayRate : double allowance : double commission : double calculateSalary( ) salary : double calculateSalary( ) salary : double calculateSalary( ) salary : double

42. Staff name : String staffNumber : String calculateSalary( ) salary : double Inheritance & Method Overriding • By Inheritance, • subclass inherits all attributes/behaviors superclass • Clerk, Manager, Director will inherit everything from superclass Staff : • the attributes “name” & “staffNumber” & • the behavior “calculateSalary” • By Method Override, • subclass define & use its behaviors overriding the inherited ones from super class Overriding Staff’s method to handle OT pays Clerk Manager Director otPayRate : double allowance : double commission : double calculateSalary( ) salary : double calculateSalary( ) salary : double calculateSalary( ) salary : double

43. Advantages • Whatever changes to the super class’s attributes & behaviors, those changes will apply to subclasses • Thus, minimizes the maintenance efforts of attributes and behaviors • enables programs to be written to manipulate general Staff objects • since objects of subclasses {Clerk, Manager, Director} can be treated as objects of super class {Staff}, so subclasses can accept the same messages and perform the behaviorsthat a super class object accepts (even though subclasses may have method overriding) • Then, it is convenient to send the same message calculateSalary to every Staff object, and they will calculate their own salaries properly. This is called polymorphism

44. Animal weight : double age : double lifeLength : double eat( ) sleep( ) move( ) reproduce( ) Snake Lizard Lion elephant Bird fly( ) Hawk Owl Class Hierarchy • At top-level, • Since Animal defines all attributes & behaviors, so Animal is a generalclass while the others are specificclasses, • middle level, Bird plays dual roles • specific class of Animal • general class of Hawk & Owl • arrow draws from specific to general • Remarks : Top level Middle level

45. E) Case Studies • With courteous of Vicmon FAN (group-8), please refer to his Web Version as follows : • [ http://learn.ouhk.edu.hk/~t430859/mt201/note/unit2/noteUnit2-2.htm ]

46. F) Appendix - a Diagram with different Names ? • Object Interaction Diagram (p-22) • Operational Diagram (p-47) • Message Sending Diagram (p-49) • anyway it looks like “Collaboration Diagram” in UML • ref. pp-89, The UML Ref Manual, Addison Wesley, 1999 • UML = Unified Modeling Language ( Out syllabus )