Object-Oriented Systems Development:

Transcription

1 Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 1: An Overview of Object-Oriented Systems Development

2 Goals The object-oriented philosophy and why we need to study it. The unified approach.

3 Introduction Object-Oriented (OO) systems development is a way to develop software by building self-contained modules that can be more easily: Replaced Modified and Reused.

4 What is a Software development methodology? Is a series of process that, can lead to the development of applications Practices, procedures, and rules used to develop software The s/w process describe how the work is to be carried out to achieve the original goal

5 Systems Development Methodologies Systems development methodology is a way to develop system or s/w by building self contained modules or objects that can be easily. Replaced, modified, and reused A comprehensive system development methodology utilizes sets of tools as well as the style in which they are to be used.

6 Methodology In an O-O environment, software is a collection of discrete objects. These objects encapsulate their data and functionalities to model real world "objects. In an object-oriented system, everything is an object and each object is responsible for itself.

7 Methodology (cont ) For Ex. Every windows application needs windows objects that can open themselves on screen and either display something or accept input. The windows object is responsible for things like opening, sizing and closing itself Frequently, when a window displays something, that something also is an object

8 Methodology (Con t) An object-oriented life cycle encourages a view of the world as a system of cooperative and collaborating agents.

9 Benefits of Object Orientation Faster development, Reusability, Increased quality, and easier maintenance.

10 OO Benefits (Con t) Object technology emphasizes modeling the real world and provides us with the stronger equivalence of the real world s entities (objects) than other methodologies. Raising the level of abstraction to the point where application can be implemented in the same terms as they are described.

11 Unified Approach The unified approach (UA) is a methodology for software development that is used in this book. The UA, based on methodologies by Booch, Rumbaugh, Jacobson, and others, tries to combine the best practices, processes, and guidelines.

12 Unified Approach (Con t) UA utilizes the unified modeling language (UML) which is a set of notations and conventions used to describe and model an application. The heart of the UA is Jacobson's use case.

13 Layered Architecture UA also uses a layered architecture to develop applications. The layered approach consists of view or user interface, business, and access layers.

14 Layered Architecture (Con t) This approach reduces the interdependence of the user interface, database access, and business control. Therefore, it allows for a more robust and flexible system.

15 M em ber comes in Ret u r n Bo o k? Ye s Bo r r o w Bo o k s? No Pe r f o r m Res e ar c h? No Re a d n e ws p a p e r / b o o k s G o t o c ount er a n d r e t u r n t h e b o o k Ye s No I n t e r L ibr a y L o a n? 1 No Ye s Ye s * Ye s I nt e r Lib r ar y L o a n Se c t io n, c h e c k o u t b o o k Sea r c h f o r t he b o o k in t h e lib r a r y Do Res ea r c h o n t h e t o p ic Sit s om ewhe r e q uie t a nd r e a d n ews pa pe r, b o o k s, e t c. 1 1 * Do n e? Ye s Ch e c k in g o u t Bo o k s? G o t o c o u n t a n d c h e c k o u t h e b o o k Bank Client ATM M achine Account Request Kind Ent er Kind Request Am ount Ent er Am ount Dispense Cash Request Take Cash Take Cash Request Cont inuat ion Ter m inat e Pr int Receipt Checking Account Pr ocess Tr ansact ion W it hdr aw Checking Account Tr ansact ion succeed W it hdr aw Successf ul Ac ces s Clas s ( es ) BankDB Vi anet Bank ATM Account Chec kingac c ount Syt em #s av ings : Ac count +w i t hdr a w ( ) insufficient funds 1.. * Ac c ount #num ber : St r ing #balance : f loat #bankclient : BankClient #t r ans ac t ion: Tr ans ac t ion 1 Bank Client #f ir s t Nam e : St r ing #las t Nam e : St r ing #c ar dnum ber : St r ing #pinnum ber : St r ing #ac c ount : Ac c ount +ver i f ypassw or d( ) +de pos i t ( ) +w i t hdr a w ( ) # r e t r i e v e Ac c ount ( ) #updat eaccount ( ) # c r e at e Tr a ns ac t i on( ) Sav ings - Chec king 1 1 * Account - Tr ansact ion Sav ings Ac c ount #c heck ing : Acc ount ATM M ac hine #addr ess : St r ing #s t at e : St r ing Tr ansact ion #t r ans I D : St r ing #t r ans Dat e : Dat e #t r ans Tim e : Tim e #t r ans Ty pe : St r ing #am ount : f loat #post Balance : f loat #ac c ount : Acc ount CheckingAccount::+withdraw (anamount:float):returncode:string Wi t hdr aw usi ng Account cl ass Account. w i thdraw (anamount) m et hod + r e t r i e v e Cl i e n t ( ) + u pd a t e Cl i e nt ( ) + r e t r i e v e Sa v i n g s Ac c o u nt ( ) +updat esavi ngsaccount ( ) + r e t r i e v e Ch e c k i n gac c o un t ( ) +upda t e Che c ki ngacc ount ( ) sufficient funds returncode = "O K" Busines s Clas ses sufficient funds Ba nk Clie n t # f ir s t Na m e : St r ing # la s t Na m e : St r in g # c ar d Nu m b e r : St r in g # pinnum ber : St r ing # a c c o u n t : Ac c o un t # b an k DB: Ba nk DB + v e r i f y Pa s s w o r d ( ) Ch ec k in g Ac c o un t Ha s # s av in g s : Ac c o u n t + w i t h d r a w ( ) - r e t r i e v e Ac c o u n t ( ) - u pd a t e Ac c o un t t ( ) account w i t hdr aw usi ng Savi ngsaccount 1 m et hod 1.. * Ac c o u n t # num ber : St r ing # balance : f loat Doesn't have savi ngs acount has savings account insufficient funds Ba nk # bankclient : BankClient # t r ans act ion: Tr ans ac t ion # b an k DB: Ba nk DB + d e p o s i t ( ) + w i t h d r a w ( ) # c r e a t e Tr a n s a c t i on ( ) # r e t r i e v e Ac c o u n t ( ) # u pd a t e Ac c o un t t ( ) 1 Sa v in g s - Ch ec k in g Savi ngsaccount. w i t hdr aw Savi ngsaccount. bal ance - ( anam ount - CheckAccount. bal ance) ) 1 * Account - Tr ans ac t ion 1 r et ur ncode ="I nsuf f i ci ent f unds" ATM M achine # a dd r e s s : St r in g # s t a t e : St r in g Sa v in g s Ac c o u nt # c he c k in g : Ac c o u nt Tr ans ac t ion # t r a n s I D : St r in g # t r a n s Dat e : Da t e # t r anstim e : Tim e # t r ans Type : St r ing # a m o u n t : f loa t # post Balance : f loat # a c c o u n t : Ac c o u nt - r e t r i e v e Ac c o u n t ( ) - u pd a t e Ac c o un t t ( ) I s easy t o operat e: How do you rat e the ViaNet Bank ATM Kiosk I nt erface? Ve r y e a s y t o u s e But t ons are r i ght si ze and easi l y can be l ocat ed: I s ef f i ci ent t o use: I s Fun t o use: I s vi sual l y pl easi ng: V e r y a p p r o p r i a t e V e r y e f f i c i e n t Ve r y Ve r y pl e a s i ng Provi des easy recovery f rom er rors: Com m ent s: Ve r y e a s y r e c ov e r y I hav e m or e t o say, I would lik e t o s ee y ou Ve r y Ha r d t o u s e No t a p p r o p r i a t e V e r y i n e f f i c i e n t Not Fun a t a l l Not pl e a s i ng Not a t a l l Analysis Design Prototyping and Testing 1. Identify the users/actors (Chapter 6): Who is (or will be) using the system? 2. Develop a simple business process model The advantage of developing a business process model is that it familiarizes you with the system and therefore the user requirements 3. Develop the use case (Chapter 6): What are (or will be) the users are doing with the system? Use cases provide comprehensive documentation of the system under study Use cases capture the goal of the users and the responsibility of the system to its users Business process modeling using activity diagram Use case diagrams 4. Interaction diagrams (Chapter 7) 4.1 Develop sequence diagrams 4.2 Develop collaboration diagrams. 4.3 Iterate and refine collaboration diagram 5. Classification (Chapter 8) 5.1 Identify Classes 5.2 Identify Relationships 5.3 Identify Attributes 5.4 Identify Methods 5.5 Iterate and refine. Class diagram The process of creating sequence or collaboration diagrams is a systematic way to think about how a use case can take place, and by doing so, it forces you to think about objects involves in your application Sequence diagram 6. Apply design axioms to design classes, their attributes, methods, associations, structures, and protocols (Chapter 9) 6.1. Refine and complete the static UML class diagram (object model) by adding details to the UML class diagram (Chapter 10) Refine attributes Design methods and protocols by utilizing UML activity diagram for representation of method s algorithm Refine (if required) associations between classes Refine (if required) class hierarchy and design with inheritance 6.2 Iterate and refine (reapply Design axioms). 7.0 Design the access ayer (Chapter 11) 7.1. Create maccess layer classes by mirroring the business classes 7.2. Define relationships 7.3. Simplify classes and structures Eliminate redundant classes Eliminate method classes 7.4 Iterate and refine Refine UML Class diagram Design methods by utilizing UML Activity Diagram UML Class diagram with added access and view classes 8. Designing view layer classes (Chapter 12) 8.1 Macro-level UI design Process- Identifying View layer Objects 8.2 Micro-level UI design activities: Designing the view layer objects by applying design axioms and corollaries Prototyping the view layer interface Usability and user satisfaction testing (Chapter 14): 8.4 Iterate and refine 9. Iterate and refine the design/analysis: If needed repeat the preceding steps Cre a te Us e r In te rfa c e c o n tro l s As s o c i a te a c ti o n s to th e Us e r In te rfa c e c o n tro l s a n d th e i r e v e n ts T e s t/de b u g Do n e Enter title here Canc el Create the forms and controls Enter title here Enter title here Canc el Add Actions Canc el Test the UI Prototype user interface Usability and user satisfaction testing OK OK OK

16 Summary In an object-oriented environment, software is a collection of discrete objects that encapsulate their data and the functionality to model real-world objects.

17 Summary (Con t) An object orientation produces systems that are easier to evolve, more flexible, more robust, and more reusable than other traditional approaches.

18 Summary (Con t) This book is organized around the unified approach. The UA, based on methodologies by Booch, Rumbaugh, Jacobson, and others, tries to combine the best practices, processes, and guidelines along with the Object Management Group's Unified Modeling Language (UML).

19 Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 2: Object Basics

20 Goals Define Objects and classes Describe objects methods, attributes and how objects respond to messages, Define Polymorphism, Inheritance, data abstraction, encapsulation, and protocol,

21 Goals (Con t) Describe objects relationships, Describe object persistence, Understand meta-classes.

22 What is an object? The term object was first formally utilized in the Simula language to simulate some aspect of reality. An object is an entity. It knows things (has attributes) It does things (provides services or has methods)

23 It Knows things (attributes) I am an Employee. I know my name, social security number and my address.

24 Attributes (Con t) I am a Car. I know my color, manufacturer, cost, owner and model.

25 Attributes (Con t) I am a Fish. I know my date of arrival and expiration.

26 It does things (methods) I know how to compute my payroll.

27 Methods (Con t) I know how to stop.

28 Methods (Con t) I know how to cook myself.

29 What is an object? (Con t) Attributes or properties describe object s state (data) and methods define its behavior.

30 Object is whatever an application wants to talk about. For example, Parts and assemblies might be objects of bill of material application. Stocks and bonds might be objects of financial investment applications.

31 Objects In an object-oriented system, everything is an object: numbers, arrays, records, fields, files, forms, an invoice, etc.

32 Objects (Con t) An Object is anything, real or abstract, about which we store data and those methods that manipulate the data. Conceptually, each object is responsible for itself.

33 Objects (Con t) A window object is responsible for things like opening, sizing, and closing itself. A chart object is responsible for things like maintaining its data and labels, and even for drawing itself.

34 Two Basic Questions When developing an O-O application, two basic questions always arise. What objects does the application need? What functionality should those objects have?

35 Traditional Approach The traditional approach to software development tends toward writing a lot of code to do all the things that have to be done. You are the only active entity and the code is just basically a lot of building materials.

36 Object-Oriented Approach OO approach is more like creating a lot of helpers that take on an active role, a spirit, that form a community whose interactions become the application.

37 Object s Attributes Attributes represented by data type. They describe objects states. In the Car example the car s attributes are: color, manufacturer, cost, owner, model, etc.

38 Object Behavior and Methods When we talk about elephant or a car, a set of things we normally do with it or that it can do in its own. We can drive a car, we can ride an elephant or elephant eat a peanut. Each of these statements is a description of the object s behavior In object model, object behavior is described in methods or procedures. A method implements the behavior of an object Behavior denotes the collection of the methods that abstractly describes what an object capable of doing.

39 Object s Methods Methods define objects behavior and specify the way in which an Object s data are manipulated. In the Car example the car s methods are: drive it, lock it, tow it, carry passenger in it.

40 Objects are Grouped in Classes The role of a class is to define the attributes and methods (the state and behavior) of its instances. The class car, for example, defines the property color. Each individual car (object) will have a value for this property, such as "maroon," "yellow" or "white."

41 Employee Class John object Jane object Mark object

42 A Class is an Object Template, or an Object Factory. B o e in g A irp la n e O b je c ts (B o e in g in s ta n c e s )

43 Objects Respond to Message An objects capabilities are determined by methods defined it Methods conceptually are equivalent to the function definitions used in procedural languages For Ex. A draw method would tell a chart how to draw itself, to do an operation, message is sent to an object. Objects perform operations in response to message. For Ex. when you press on the break pedal of a car, you send a stop message to the car object. The car object knows how to respond to the stop message.

44 Objects Respond to Message cont.. A message is different from subroutine call,, since different objects can respond to the same message in different ways For Ex.cars, motorcycles, and bicycles will all respond to a stop message, but actual operations performed are object specific To understand the difference between methods and messages. Say you want to tell some one to make you French onion soup. Your instruction is the message, the way the French onion soup is prepared is the method, and the French onion soup is the object

45 Class Hierarchy An object-oriented system organizes classes into subclass-super hierarchy. At the top of the hierarchy are the most general classes and at the bottom are the most specific

46 Class Hierarchy (Con t) A subclass inherits all of the properties and methods (procedures) defined in its superclass. Motor Vehicle Bus Truck Car

47 Class Hierarchy (Con t) Subclasses generally add new methods and properties specific to that class. Subclasses may refine or constrain the state and behavior inherited from its super class. For Ex, race cars only have one occupant, the driver, In this manner the sub classes modify the attribute(number of passengers) of its super class car

48 Vehicle Car Ford Mustang Taurus Thunderbird

49 Inheritance (programming by extension ) Inheritance is a relationship between classes where one class is the parent class of another (derived) class.

50 Inheritance (Con t) Inheritance allows classes to share and reuse behaviors and attributes.

51 Inheritance (Con t) For Ex, the car class define the general behaviour of cars. The Ford class inherits the general behaviour from the car class and adds behaviour specific to fords. It is not necessary to redefine the behaviour of the car class; this is inherited. Another level down, the Mustang class inherits the behaviour of cars from the car class end even more specific behaviour of fords from the Ford class The mustang class then adds behaviour unique to Mustang

52 Inheritance (Con t) Assume that all Fords use the same breaking system In that case, the stop method would be defined in ford class, since it is a behavior shared by all objects of a class ford. When you step on the break pedal of a Mustang, you send a stop message to Mustang object. However, the stop method is not defined in the Mustang class, so the hierarchy is search until a stop method is found The stop method is found in a Ford class, and it is invoked

53 Inheritance (Con t) Vehicle Car I know how to stop stop method is reusable Ford M ustang Taurus Thunderbird I don t know how to stop stop (mym ustang)

54 Multiple Inheritance OO systems permit a class to inherit from more than one superclass. This kind of inheritance is referred to as multiple inheritance.

55 Multiple Inheritance (Con t) For example utility vehicle inherits attributes from Car and Truck classes. MotorVehicle Truck Car Bus UtilityVehicle

56 Encapsulation and Information Hiding Information hiding is a principle of hiding internal data and procedures of an object. Permissible operations Data Private Protocol Public Protocol Massages

57 Encapsulation and Information Hiding (Con t) By providing an interface to each object in such a way as to reveal as little as possible about its inner workings. Encapsulation protects the data from corruption.

58 Protocol Protocol is an interface to the object. TV contains many complex components, but you do not need to know about them to use it.

59 Message Objects perform operations in response to messages. For example, you may communicate with your computer by sending it a message from handhelp controller.

60 A Case Study - A Payroll Program Consider a payroll program that processes employee records at a small manufacturing firm. This company has three types of employees: 1. Managers: Receive a regular salary. 2. Office Workers: Receive an hourly wage and are eligible for overtime after 40 hours. 3. Production Workers: Are paid according to a piece rate.

61 Structured Approach FOR EVERY EMPLOYEE DO BEGIN IF employee = manager THEN CALL computemanagersalary IF employee = office worker THEN CALL computeofficeworkersalary IF employee = production worker THEN CALL computeproductionworkersalary END

62 What if we add two new types of employees? Temporary office workers ineligible for overtime, Junior production workers who receive an hourly wage plus a lower piece rate.

63 FOR EVERY EMPLOYEE DO BEGIN IF employee = manager THEN CALL computemanagersalary IF employee = office worker THEN CALL computeofficeworker_salary IF employee = production worker THEN CALL computeproductionworker_salary IF employee = temporary office worker THEN CALL computetemporaryofficeworkersalary IF employee = junior production worker THEN END CALL computejuniorproductionworkersalary

64 An Object-Oriented Approach What objects does the application need? The goal of OO analysis is to identify objects and classes that support the problem domain and system's requirements. Some general candidate classes are: Persons what role does a person play in the system? Places these are physical locations, buildings, stores, sites or offices about which the system keep information Things point in time that system must be recorded (ex. Order, cust-id, order date)

65 What are some of the application s classes? Employee Manager Office Workers Production Workers

66 Class Hierarchy Identify class hierarchy Identify commonality among the classes Draw the general-specific class hierarchy.

67 Class Hierarchy (Con t) Employee name address salary SS# OfficeWorker Manager ProductionWorker dataentry ComputePayroll printreport dataentry ComputePayroll printreport dataentry ComputePayroll printreport

68 OO Approach FOR EVERY EMPLOYEE DO BEGIN employee computepayroll END

69 If a new class of employee were added E m ployee nam e address salary SS# O fficew orker M an ager P rodu ctionw orker datae ntry C om putep ayroll printr eport datae ntry C om putep ayroll printr eport datae ntry C om putep ayroll printr eport T em poraryo fficew orker JuniorP roductionw orker C om putep ayroll C om putep ayroll

70 Polymorphism Polymorphism means that the same operation may behave differently on different classes. Example: computepayroll

71 Associations The concept of association represents relationships between objects and classes. For example a pilot can fly planes. Associations are bidirectional- they traverse in both directions The directions implied by the name is the forward direction The opposite direction is the inverse direction The important issue in association is Cardinality, which specifies how many instance of one class may relate to a single instance of an associated class

72 Associations (Con t) Pilot can fly flown by Planes

73 Consumer producer associaton or Clients and Servers A special form of association is a client-server relationship. This relationship can be viewed as one-way interaction: one object (client) requests the service of another object (server).

74 Clients and Servers (Con t) PrintServer Request for printing Item

75 Aggregations All objects, except the most basic ones, are composed of other objects or may contain other objects For Ex. A spreadsheet is an object composed of cells, cells are object that may contain text or mathematical formulas etc. This is an Aggregation, where an attribute can be an object itself

76 Aggregation CAR Engine Seat Wheel

77 Objects and Persistence Objects have a lifetime. An object can persist beyond application session boundaries, during which the object is stored in a file or a database, in some file or database form.

78 Meta-Classes Everything is an object. How about a class? Is a class an object? Yes, a class is an object! So, if it is an object, it must belong to a class. Indeed, class belongs to a class called a Meta-Class or a class' class.

79 Meta-Classes (Con t) Meta-class used by the compiler. For example, the meta-classes handle messages to classes, such as constructors and "new."

80 Summary Rather than treat data and procedures separately, object-oriented programming packages them into "objects." O-O system provides you with the set of objects that closely reflects the underlying application

81 Summary (Con t) Advantages of object-oriented programming are: The ability to reuse code, develop more maintainable systems in a shorter amount of time.

82 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 3: Object-Oriented Systems Development Life Cycle

83 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Goals The software development process Building high-quality software Object-oriented systems development

84 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Goals (Con t) Use-case driven systems development Prototyping Rapid application development Component-based development Continuous testing and reusability

85 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Software Development process Software Development process consists of analysis, design, implementation, testing and refinement is to transformation of Users needs to The application domain into A software solution.

86 Software Development process System development can be viewed as a process The development itself, is a process change, refinement, transformation, or addition to the existing product. Within the process, it is possible to replace one sub process with a new one Each sub process must have A description in terms of how it works Specification of the input required for the process Specification of the out to be produces Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill

87 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Software Development process The software development process also can be divided into smaller, interacting sub process Generally, the software development process can be viewed as a series of transformations, Where the output of one transformation becomes the input of the subsequent transformation (see the fig)

88 Software Process (Con t) What are the uses of the system.? Needs Need Transformation 1 Analysis Transformation 2 Problem Statements Analysis Design Design Implementation Transformation 3 System Software Detail implementation Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Product

89 Software Development process cont.. Transformation 1 (analysis) translates the users needs into system requirements and responsibilities The way they use the system can provide insight into the user requirements Transformation 2 (Design) begins a problem of statement and ends with detailed design that can be transformed into an operational system

90 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Software Development process cont.. This transformations includes the bulk of s/w development activity Including definition of how to build the s/w Its development And its testing Transformation 3(Implementation) refines the detailed design into the system deployment that will satisfy the user s needs.

91 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill An example of s/w development process is the Traditional Waterfall Approach W h a t H o w D o It T e st U se

92 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Software Development process cont.. In the real world, the problem are not always well-defined and that is why the waterfall model has limited utility Where there is uncertainty regarding what is required or how it can be built, the waterfall model fails This model assume that the requirements are known before the design begins

93 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Building high Quality Software There are two basic approaches to systems testing. We can test a system according to how it has been built. Alternatively, we can test the system with respect to what it should do.

94 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Quality Measures Systems can be evaluated in terms of four quality measures: Correspondence Correctness Verification Validation

95 Quality Measures (Con t) Correspondence measures how well the delivered system corresponds to the needs of the operational environment. N e e d s R e q u i r e m e n t s D e s i g n S o f t w a r e C o r r e s p o n d e n c e Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill

96 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill How would you determine Correspondence? It cannot be determined until the system is in place.

97 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Quality Measures (Con t) Correctness measures the consistency of the product requirements with respect to the design specification. N e e d s R e q u ir e m e n ts D e s ig n S o f tw a r e C o r r e c tn e s s

98 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Quality Measures (Con t) Verification - "Am I building the product right?" Validation - "Am I building the right product?" V a lid a tio n V e r ific a tio n N e e d s R e q u ir e m e n ts D e s ig n S o f tw a r e

99 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Quality Measures (Con t) Verification is to predict the correctness. Validation is to predict the correspondence.

100 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill OBJECT-ORIENTED SYSTEMS DEVELOPMENT USE-CASE DRIVEN APPROACH : A The object-oriented software development life cycle (SDLC) consists of three macro process Object- oriented analysis Object-oriented design Object-oriented implementation

101 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Approach Builduse-case model Use-Cases Object analysis O-O Analysis Validate/ Test Validate/ test Iteration and Reuse Using TOOLS CASE and/or OO programing languages User satisfaction Usability & QA Tests O-O Implementation Design classes, define attributes and methods O-O Design Build object & dynamic model Build UI and prototype U ser satisfaction test, usability test quality assurance test

102 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill activities The use-case model can be employed throughout most activities of software development. Object-oriented analysis. Object-oriented design. Prototyping. Component-based development. Incremental testing.

103 Object-oriented analysis - Use-case driven Use Case, is a name for a scenario to describe the user computer system interaction. Use case models/ documnet OOA: Identify Actors Object interaction diagram, etc. Dynamic model OOA: Object Model OOA: Use case Model Design classes UI OOD: Dynamic model Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill OOA: Courses of action Testing: Usage Scenarios

104 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Object-Oriented Analysis OO analysis concerns with determining the system requirements and identifying classes and their relationships that make up an application. To understand the system requirements, we need to identify the users or the actors Who are the actors and how do they use the system Use- case modeling - represents the user s view of the system or user needs

105 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Object-Oriented Design The goal of object-oriented design (OOD) is to design: The classes identified during the analysis phase, The user interface and Data access.

106 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Object-Oriented Design (Con t) OOD activities include: Design and refine classes. Design and refine attributes. Design and refine methods. Design and refine structures. Design and refine associations. Design User Interface or View layer classes. Design data Access Layer classes.

107 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Prototyping A Prototype enables you to fully understand how easy or difficult it will be to implement some of the features of the system. It can also give users a chance to comment on the usability and usefulness of the design.

108 Types of Prototypes A horizontal prototype is a simulation of the interface but contains no functionality This has the advantage of being very quick to implement, providing a good overall feel of the system And allowing users to evaluate the interface on the basis of their normal, expected perception of the system Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill

109 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Types of Prototypes A vertical prototype is a subset of the system features with complete functionality. Advantage of this method is that few implemented functions can be tested in great depth

110 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Types of Prototypes (Con t) An analysis prototype is an aid for exploring the problem domain. This class of prototype is used to inform the user and demonstrate the proof of a concept Is not used as the basis of development, however, and is discarded when it has served its purpose

111 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Types of Prototypes (Con t) A domain prototype is an aid for the incremental development of the ultimate software solution. It often used as a tool for the staged delivery of subsystems to the users or the members of the development team.

112 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Implementation : Component-based development (CBD) CBD is an industrialized approach to the software development process. Application development moves from custom development to assembly of prebuilt, pre-tested, reusable software components that operate with each other.

113 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Implementation : Component-based development (CBD) CBD developers can assemble components to construct a complete software system Components themselves may be constructed from other components and so on down to the level of prebuilt components or old-fashioned code written in a language like C, COBOL, visual tools ect.

114 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Implementation : Component-based development (CBD) Existing (legacy) applications support critical services within an organization and therefore cannot be thrown away. Massive rewriting from scratch is not a viable option, as most legacy applications are complex, massive, and often poorly documented.

115 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Implementation : Component-based development (CBD) The CBD approach to legacy integration involves application wrapping, in particular component wrapping, technology. An application wrapper surrounds a complete system, both code and data. This wrapper then provide an interface that can interact with both the legacy and the new software systems.

116 Component-based development (CBD) Con t) Component wrapper Component wrapper Subselect and enter title here Legacy programs Legacy data Open Connectivity Component wrapper Component wrapper Legacy screens Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Legacy software packages

117 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Rapid Application Development (RAD) RAD is a set of tools and techniques that can be used to build an application faster than typically possible with traditional methods.

118 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Rapid Application Development (RAD) (Con t) RAD does not replace SDLC but complements it, since it focuses more on process description and can be combined perfectly with the object-oriented approach.

119 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Incremental Testing Software development and all of its activities including testing are an iterative process. If you wait until after development to test an application for bugs and performance, you could be wasting thousands of dollars and hours of time.

120 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Reusability A major benefit of object-oriented systems development is reusability, and this is the most difficult promise to deliver on.

121 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Reuse strategy Information hiding (encapsulation). Conformance to naming standards. Creation and administration of an object repository.

122 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Reuse strategy (Con t) Encouragement by strategic management of reuse as opposed to constant redevelopment. Establishing targets for a percentage of the objects in the project to be reused (i.e., 50 percent reuse of objects).

123 Object-Oriented Systems Development Bahrami Irwin/ McGraw-Hill Summary The essence of the software process is the transformation of users needs into a software solution. The O-O SDLC is an iterative process and is divided into analysis, design, prototyping/ implementation, and testing.