1. 11 Software Engineering Dr. K. T. Tsang Lecture 4 Object-Oriented concepts http://www.uic.edu.hk/~kentsang/SWE/SWE.htm

2. 2 Before we write any code, we need Establishing Requirements: The goal of this is to spell out what constitutes a satisfactory solution to the problem. Analysis: The goal here is to understand the problem (domain) comprehensively. Design: The goal here is to develop the overall structure of a (SW) solution to the problem in terms of individual (SW) components and their relationships to one another.

3. 3 How ?? All these tasks require modeling activities To better understand the problem we have, we need a model for the domain where the SW will operate on. Modeling – building a model that has all relevant features of the domain area which we are interested. This will help to better understand the domain and make the Analysis part of the development process easier.

4. 4 What is Design? Developing a blueprint (plan) for a SW architecture that can satisfy the requirements, … taking into account all the constraints, & … making trade-offs between constraints when they are in conflict.

5. 5 Factors affecting the quality of a software system Complexity: –The system is so complex that no single programmer can understand it anymore –The introduction of one bug fix causes another bug Change: –The “Entropy” of a software system increases with each change: Each implemented change erodes the structure of the system which makes the next change even more expensive –As time goes on, the cost to implement a change will be too high, and the system will then be unable to support its intended task. This is true of all systems, independent of their application domain or technological base.

6. 6 Why are software systems so complex? The problem domain is difficult The development process is very difficult to manage Software offers extreme flexibility (complicated) Software is a discrete system –Continuous systems have no hidden surprises –Discrete systems have!

7. 7 Dealing with Complexity 1.Abstraction 2.Decomposition 3.Hierarchy

8. 8 1. Abstraction Inherent human limitation to deal with complexity –The 7 +- 2 phenomena Chunking: Group collection of objects Ignore unessential details: => Models

9. 9 Models are used to provide abstractions System Model: –Object Model: What is the structure of the system? What are the objects and how are they related? –Functional model: What are the functions of the system? How is data flowing through the system? –Dynamic model: How does the system react to external events? How is the event flow in the system ? Task Model: –PERT [Program (or Project) Evaluation and Review Technique] Chart: What are the dependencies between the tasks? –Schedule: How can this be done within the time limit? –Org Chart: What are the roles in the project or organization? Issues Model: –What are the open and closed issues? What constraints were posed by the client? What resolutions were made?

10. 10 The “Bermuda Triangle” of Modeling System Models Issue Model Task Models PERT Chart Gantt Chart Org Chart Constraints Issues Proposals Arguments Object Model Functional Model Dynamic Model class... Code Pro Con Forward Engineering Reverse Engineering

11. 11 2. Decomposition 11 A technique used to master complexity (“divide and conquer”) Functional decomposition –The system is decomposed into modules –Each module is a major processing step (function) in the application domain –Modules can be decomposed into smaller modules Object-oriented decomposition –The system is decomposed into classes (“objects”) –Each class is a major abstraction in the application domain –Classes can be decomposed into smaller classes

12. 12 Functional Decomposition Top Level functions Level 1 functions Level 2 functions Machine Instructions System Function Load R10 Add R1, R10 Read Input Transform Produce Output Transform Produce Output Read Input

13. 13 Functional Decomposition Functionality is spread all over the system Maintainer must understand the whole system to make a single change to the system Consequence: –Codes are hard to understand –Code that is complex and impossible to maintain –User interface is often awkward and non- intuitive 13

14. 14 Autoshape Functional Decomposition: Autoshape Draw Rectangle Draw Oval Draw Circle Draw Change Mouse click Change Rectangle Change Oval Change Circle Example: Microsoft Powerpoint’s Autoshapes

15. 15 Structured SW paradigm The structured paradigm consists of structured systems analysis, structured design, structured programming and structured testing. They were introduced between 1970 and 1985, and looked promising at the time. Two problems with structured paradigm: –Could not scale up: Good for products with 5,000 or 50,000 LOC (lines of code), but inadequate for products with 500,000 LOC or more. –Could not reduce maintenance costs. 15

16. 16 Structured SW paradigm The reason is that structured techniques are either action oriented (such as data flow analysis) or data oriented (such as Jackson method) but not both. Object-oriented paradigm considers data and action to be of equal importance. 16

17. 17 Structured paradigm vs. OO 17

18. 18 What is OO Analysis and Design Object-Oriented Analysis –Important domain concepts or objects? –Domain vocabularies? Object-Oriented Design –Design of software objects –Responsibilities –Collaborations –Design patterns

19. 19 History of OO 19 Object orientation as a concept has been around since the 1970's –as a design concept since 1980 It was in the 1980's that it started to develop as a credible alternative to the structured approach in analysis and design.

20. 20 Why OO? We can identify a number of drivers. –The emergence of mainstream OO programming languages like SmallTalk and particularly C++, a pragmatic OO language derived from C, widely used because of its association with Unix. –The development of powerful workstations, and with them the emergence into the mainstream of windowing operating user environments. Graphical User Interfaces (GUI) have an inherent object structure. –A number of very public major project failures, suggesting that structured approaches were not satisfactory. 20

21. 21 OO concepts Object-Orientation treats the world as a world of objects, which contain –(hidden) information –Methods (aka behaviors) –A public interface This structure provides encapsulation –Data & behavior are private; as long as the public interface remains unchanged, the data & behavior of an object can be freely modified. 21

22. 22 3 basic OO concepts Encapsulation Inheritance- subclasses Polymorphism- different implementation of a particular functionality

23. 23 Benefits Two benefits from this approach are –Understanding of the system is easier as the semantic gap between the system & reality is small. –Modifications to the model tend to be local as they often result from an individual item, which is represented by a single object. 23

24. 24 Message Passing Objects communicate with each other via message passing –The only way an object can access info contained in another object –No data duplication –Messages sent or received are determined by objects’ public interfaces 24

25. 25 Object & class Objects are organized into classes by their common features –Attributes (aka data) Represent the object’s state or capture associations/relationship with other objects –Operations/methods (behavior) Procedures or services the object can perform –Invariants (this is new!) Specify how the other features of the object are related 25

26. 26 Classes A class is a collection of objects which share common attributes & methods –A template for creating instances (aka objects) 26

27. 27 Class Identification Class identification is crucial to object-oriented modeling Basic assumption: 1.We can find the classes for a new software system: We call this Greenfield Engineering 2.We can identify the classes in an existing system: We call this Reengineering 3.We can create a class-based interface to any system: We call this Interface Engineering Why can we do this? Philosophy, science, experimental evidence What are the limitations? Depending on the purpose of the system different objects might be found –How can we identify the purpose of a system?

28. 28 What is this Thing?

29. 29 Modeling a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry()

30. 30 A new Use for a Briefcase BriefCase Capacity: Integer Weight: Integer Open() Close() Carry() SitOnIt()

31. 31 Questions Why did we model the thing as “Briefcase”? Why did we not model it as a chair? What do we do if the SitOnIt() operation is the most frequently used operation? The briefcase is only used for sitting on it. It is never opened nor closed. –Is it a “Chair” or a “Briefcase”? How long shall we live with our modeling mistake?

32. 32 Dealing with Complexity 1.Abstraction 2.Decomposition 3.Hierarchy

33. 33 3. Hierarchy We got abstractions and decomposition –This leads us to chunks (classes, objects) which we view with object model Another way to deal with complexity is to provide simple relationships between the chunks One of the most important relationships is hierarchy 2 important hierarchies –" Part of " hierarchy –" Is-kind-of " hierarchy

34. 34 Part of Hierarchy Computer I/O Devices CPU Memory Cache ALU Program Counter

35. 35 Is-Kind-of Hierarchy Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth RedWhite Cortical Pyramidal

36. 36 So where are we right now? Three ways to deal with complexity: –Abstraction –Decomposition –Hierarchy Object-oriented decomposition is a good methodology –Unfortunately, depending on the purpose of the system, different objects can be found How can we do it right? –Many different possibilities –Our current approach: Start with a description of the functionality (Use case model), then proceed to the object model –This leads us to the software lifecycle

37. 37 Software Lifecycle Activities Subsystems Structured By class... Source Code Implemented By Solution Domain Objects Realized By System Design Object Design Implemen- tation Testing Application Domain Objects Expressed in Terms Of Test Cases ? Verified By class.... ? Requirements Elicitation Use Case Model Analysis...and their models

38. 38 UML Overview UML is a diagramming standard for diagrams to aid the design process –A picture is worth 1000 words (visualization) –A common picture language helps just like a common verbal language (English, French, etc) does. –UML greatly facilitates object-oriented/architecture- centric design: all of the diagrams but two center on the object/component structure.

39. 39 History of UML A number of researchers (Yourdon, Booch, Rumbaugh, Jacobson …) proposed OOA&D processes, and with them different notations. During the early 1990's it became clear that these approaches had many good ideas, often very similar. A major stumbling block was the diversity of notation, meaning engineers tended to be familiar with one OOA&D methodology, rather than the approach in general. In the interests of all involved, UML (Unified Modeling Language) was conceived as a common notation. 39

40. 40 History of UML (2) The original standard was driven by Rational Software (in which three of the key researchers in the field, Booch, Jacobson and Rumbaugh were involved). The effort was taken industry wide through the Object Management Group (OMG), already well known for the CORBA standard. A first proposal, 1.0 was published in early 1997, with an improved version 1.1 approved that autumn. 40

41. 41 What is the UML? UML stands for Unified Modeling Language The UML combines the best of the best from –Data Modeling concepts (Entity Relationship Diagrams) –Business Modeling (work flow) –Object Modeling –Component Modeling The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system It can be used with all processes, throughout the development life cycle, and across different implementation technologies 41

42. 42 UML Concepts The UML may be used to: –Display the boundary of a system & its major functions using use cases and actors –Illustrate use case realizations with interaction diagrams –Represent a static structure of a system using class diagrams –Model the behavior of objects with state transition diagrams –Reveal the physical implementation architecture with component & deployment diagrams –Extend your functionality with stereotypes 42

43. 43 Three system models in UML Class model (static view of objects) –Class diagram State model (dynamic view of objects) –State diagram Interaction model (system behavior/functions, how objects cooperate) –Use case (users, actors) –Sequence diagram –Activity diagram

44. 44 System models in different views Interaction model Class model State model

45. 45 Class model Describes the structure of objects in a system, a static view Class diagram – allows visualization of individual classes and relationship among them

46. 46 State model Describes aspects (attributes) of objects that change with time, events that mark the changes and states that define the context of events State diagram – shows the state & event sequences permitted for all the classes in the system

47. 47 Interaction model Describes interaction between objects (how objects collaborate to achieve behavior of the system as a whole) Use case – interaction between system & actors (7.1.2 in Blaha & Rumbaugh) Sequence diagram – time sequence of interactions between objects (7.2) Activity diagram – flow of control during interaction (7.3)

48. 48 Use-case diagrams 7.1.3 UML supports a use-case diagram It shows the relationships between the use-cases and the actors (entities outside the system acting on it) For systems with many actors and distinct activities it can be very helpful The symbol for a use case:

49. 49 Actors An actor is a type of person - or sometimes another system – that must use the system that is to be built. –Actors are not specific people - they are specific roles filled by people. Thus, the same person may need to be regarded as two or more actors if he/she relates to the system in two or more roles. –Actors are not part of the system - they are outside the system boundary and use the system. –The symbol for an actor:

50. 50 A Use-case diagram contains A box representing the system boundary. Use cases are inside the boundary; actors are outside. (Note: often, the boundary is omitted, since the it doesn’t convey any new information) The symbol for an actor: The symbol for a use case: The relationship between an actor and a use case - a solid line (technically called a communication association).

51. 51 Use Cases for a Simple Address Book

52. 52 Example: Address Book http://www.cs.gordon.edu/courses/cs211/A ddressBookExample/index.htmlhttp://www.cs.gordon.edu/courses/cs211/A ddressBookExample/index.html This is an example to develop an address book software. It contains all the phases from requirement to testing & maintenance. Study it carefully.

53. 53 Example: ATM Simulation http://www.cs.gordon.edu/courses/cs211/A TMExample/index.htmlhttp://www.cs.gordon.edu/courses/cs211/A TMExample/index.html This page is the starting point into a series of pages that attempt to give a complete example of object-oriented analysis, design, and programming applied to a moderate size problem: the simulation of an Automated Teller Machine.

54. 54 Example: Stock Brokerage System Blaha & Rumbaugh: 8.1.5 p.151 Actors: customer, security exchange Use cases: secure session, manage account, make trade, validate password…

55. 55

56. 56 Note: An actor often is associated with multiple use cases, and a single use case may be associated with more than one actor. For example, in the ATM System, a Transaction is associated with both the Customer and the Bank. Use case diagrams can also depict relationships between use cases.

57. 57 Relationships between use cases There are three general ways in which use cases can be related to each other. The generalization relationship is used when one use case generalizes several similar use cases. (For example, in the ATM system the transaction use case is a generalization of the various specific types of transaction: cash withdrawal, deposit, etc.) UML shows the generalization relationship by an arrow with its triangular arrowhead pointing to the parent use case.

58. 58 « include » & « extend » relationships The « include » relationship is used when one use case is contained within another use case. The « extend » relationship is used when one use case may be extended (under some circumstances) by some special behavior that is complex enough to warrant treating separately.

59. 59 « include » « include » is used when the included case always occurs in the including case, and it represents a goal the user might actually have, and/or as common behavior that occurs in multiple places. Example: in an ATM Session, Transaction is an inclusion, since it represents a customer goal, and every Session includes one or more transactions. UML notation: a dashed arrow from the base to the targeted (included) use case.

60. 60 « extend » « extend » is used when the extension is extraordinary (and therefore does not always occur) and is not actually a user goal. Example: in the ATM Session, “Invalid PIN” is an extension, because it is hard to imagine a customer having entering an invalid PIN as a goal, and this does not normally occur as part of an ATM Session. UML notation: a dashed arrow from the extension to the base use case.

61. 61 Stereotypes In UML terminology, « include » and « exclude » are called stereotypes. You can think of them as words having special, technical meanings. In UML, stereotypes are always enclosed in the brackets « ».

62. 62 What use-case diagrams give you It can be a very good way to start gathering the requirements They are the "big picture", showing you the whole system on a single page They can help you map fuzzy features onto more precise use-cases.

63. 63 Use case description For each use case, we need to write up a description of what needs to take place. This can be done with varying degrees of formality. A simple approach is to create a flow of events that describes that case.

64. 64 Example use cases: ATM Machine Title:Login Primary Actor: customer Secondary Actor: bank Goal: customer gets access to different account options Main Path (Main Scenario) –insert card –card id read; prompt and accept PIN input from user –if correct, display list of choices deposit/withdraw/..

65. 65 Example use cases: ATM Machine (2) Title: withdrawal Primary Actor: customer Secondary Actor: bank Goal: get money from machine Main Path (Main Scenario) –User presses withdrawal choice –Prompt for checking/savings withdrawal and user indicates –Amount of money entered –Transaction processed and authorized, money is dispensed, card and receipt returned. Alternate Path (Alternate Scenario) –Transaction not authorized, message displayed –Card immediately returned

66. 66 Format for Writing Use Cases Title which is a capsule summary, and perhaps a version number Actors involved in the use-case (for "actor", think real-world role, e.g. people: salesperson, customer; or, computer systems/components: backend database, web server, etc). The Primary Actor is the initiator, and the Secondary( supporting ) Actor(s) are any other actors. A Goal stating briefly what the use-case should do. The Pre-Condition of the use-case, a state or event that causes it to begin.

67. 67 3 kind of actors Primary actor Supporting actor – providing a service Offstage actor – has an interest in the use case, but not primary or supporting, e.g. a government tax agency.

68. 68 Format for Writing Use Cases (2) The Main Path (Main Scenario) of the use-case, which is a numbered list of actions described in English; Alternate Paths (Alternate Scenario) of the use- case Other things that may be useful to include are post-conditions that will hold when the case is all over, UML diagrams associated with the use- case (we cover that below), etc.

69. 69 Stages of requirements engineering Requirements elicitation - gathering information Requirements specification - putting the information into a document Requirements validation - checking to make sure the requirements are consistent and complete

70. 70 Example UIC is planning to build a new science building. The design of the building was based on input garnered from science division faculty and others affected by the building (e.g. the registrar had some input regarding classroom space, auditorium…). A suitable building would have to incorporate space for various purposes.

71. 71 Requirements Formulation The goal is to understand the requirements placed on the software The process goes roughly like this –Brainstorm, write down some fuzzy ideas and pictures, then make a feature list; –Next, make a first pass at the use-cases; –Check if the features we had in mind were well- covered; if not, add/modify/refine the use-cases as well as the GUI sketches, feature list, etc.

72. 72 Feature Lists You have to start somewhere, so: One good first step is to make a feature list, a list of supported features Make some GUI sketches, brainstorm, look at related software, and produce a feature list. This initial data will be helpful in the next step of refinement, writing out some use-cases. Requirement lists are closely related to feature lists, they are lists of things the software should do, including features but also including operating constraints.

73. 73 Vision Statements For larger projects you may not even be able to start with concrete features; at least start with a vision statement: Mainly an English description of what the application should do. This may include a very fuzzy list of features.

74. 74 Use-cases the primary focus of requirements gathering. A use-case is a scenario describing a series of events involving actors which describes one functionality the system should have.

75. 75 Use Cases drive the development process Before you produce any class designs, you need to have use cases Continually elaborate and expand on the use- cases, until they are defined enough to implement. Even after implementing you may want to come back and refine the use-case some more if a feature was added or missed. New use cases will arise as the implementation evolves, existing use cases may change, and some use cases may be dropped. The project development plan is driven by implementing use cases: –"implement these use cases today, those use cases tomorrow".

76. 76 Requirements & Domain Analysis Domain Analysis is a broad term meaning any activity which increases the understanding of the underlying domain the software is working in. Most of requirements gathering is in fact domain analysis. One particularly important form of domain analysis is called domain modeling or business modeling

77. 77 Domain Modeling A Domain model is a conceptual model the underlying domain, not of the actual program. Example: in a restaurant (even without a computer) the "domain" is the actual, physical restaurant and some entities in the domain include Orders, Menu Items, Payments, Receipts, waiters, etc. If you want to make a computerized ordering process it is important to have a precise idea what is happening in the physical world first. One of the best ways to make such a model is to use UML class and activity diagrams.

78. 78 Domain use cases A domain use-case is a use-case which concerns a process happening in the "real world" which –either it needs to be modeled in the software (e.g. paper invoicing process), –or the software is to interact with it (e.g. load pizzas in car, plan route and deliver). Domain use cases are, like domain modeling in general, used to better understand the application domain.

79. 79 UML and domain modeling UML class diagrams are useful for clarifying the domain entities (real or imagined) and how they relate. UML activity diagrams are useful for modeling the processes that occur in the domain.

80. 80 Reading for this lecture Chapters 1, 2, 7, 8 Blaha & Rumbaugh Study the examples in –http://www.cs.gordon.edu/courses/cs211/Addr essBookExample/index.html –http://www.cs.gordon.edu/courses/cs211/ATM Example/index.html