UNIT 1 Object Oriented Analysis and Design with
UNIT 1 Object Oriented Analysis and Design with UML 1
Coordinates Office Building F, 10 th Floor Campus Etterbeek Surface Mail Vrije Universiteit Brussel Faculty of Sciences [WE] Department of Computer Science [DINF] Programming Technology Lab [PROG] Pleinlaan 2 B-1040 Brussels Telephone +32 2 629 34 91 Telefax +32 2 629 35 25 Email luk. stoops@vub. ac. be Homepage http: //prog. vub. ac. be/ 2
Course Contents : Overview What you will learn 4 Object Oriented Paradigm (OO) 4 Analysis and Design (A&D) 4 Unified Modelling Language (UML) What you not will learn 4 OO Programming 4 Complete Coverage Rational Rose Tool 3
Course : Timing. . . Unit 1 – Introduction to Object Orientation – Introduction to Analysis & Design 4
Course : Timing. . . Unit 2 – The history of UML – General overview of UML – Use cases and scenarios – Class diagrams 5
Course : Timing. . . Unit 3 – Advanced Class diagrams – Object Interaction diagrams – A notion of Design Patterns – Antipatterns 6
Course : Timing. . . Unit 4 – Sequence diagrams – Collaboration diagrams – Activity diagram 7
Course : Timing. Unit 5 – Component diagrams – Deployment diagrams – A Process for UML : RUP 8
Book UML Toolkit Hans-Eriksson & Magnus Penker Wiley Computer Publishing © 1998, ISBN 0 -471 -19161 -2 9
UNIT 1 The Object Oriented Paradigm 10
Questions to be answered 4 Why is Object Orientation (OO) Popular? 4 Why is switching to OO not trivial 4 An Object Oriented Paradigm? 4 Overview of OO Concepts 4 Overview of OO Techniques 11
Why could OO be so Popular. . . A few possible reasons : 4 Hope that it will quickly and easily lead to increased productivity and improved reliability Ø End of the software crisis! 4 Hope for easy transition from existing languages Ø Similarity to techniques of thinking about problems in other domains 4 Everybody talks about it, our customers ask it, . . . NAÏVE APPROACH = TROUBLE ! 12
Why should OO be so Popular. 4 OO is an evolutionary step, following naturally on the heels of earlier programming abstractions 4 OO ‘solves’ many problems encountered in the traditional approaches. 4 OOP is a revolutionary idea, totally unlike anything that has come before. LET’s EVALUATE 4 OO promotes reuse IT FIRST … = BEST WAY TO GO ! 13
Questions to be answered 4 Why is Object Orientation (OO) Popular? 4 Why is switching to OO not trivial 4 An Object Oriented Paradigm? 4 Overview of OO Concepts 4 Overview of OO Techniques 14
Sapir - Whorf Hypothesis. . . 4 In Linguistics : – The language in which an idea is thought or expressed, colours or directs the nature of thought • Eskimo languages and snow • French vs Dutch : neveu, cousin vs neef – neveu = children of a brother/sister – cousin = children of an uncle/aunt 4 What is true of natural languages is true for artificial languages O O r o lly f a ci e p s E 15
Example for Computer Science. . . A student working in DNA research had the task of finding repeated sequences of M values in a long sequence of values : ACTCGGATCTTGCATTCGGCAATTGGACCCTGA. . . 4 Wrote a simple FORTRAN program with 2 nested loops : 20 10 DO 10 I=1, N-M DO 20 J=I+1, N-M FOUND =. TRUE IF X[I+K-1]. NE. X[J+K-1] THEN FOUND =. FALSE. IF FOUND THEN … CONTINUE Took a depressing long time ! 16
A Better Solution. . . A friend working in APL found another solution by rearranging the data and sorting : SORT ACTCGGATCTTGCATTCGGCAATTGGACCCTGA. . . ACTCGG TCGGAT GGATCT. . . positions 1 to M positions 2 to M+1 positions 3 to M+2 positions 4 to M+3 positions 5 to M+4 positions 6 to M+5. . . Amazingly fast ! 17
What Lead to the Discovery? 4 Why did the APL programmer find a faster solution? – FORTRAN programmer was blinded by a culture that valued loops • If M=length of pattern and N=size of string O(M*N 2) – Sorting is a built-in operation in APL (high performance), good programmers try novel uses of sorting • If M=length of pattern and N=size of string O(M*N log N) 18
General Conclusion. 4 Thoughts/solutions are often guided by the language in which they are expressed 4 Anything can be done in any language – but it may be easier or more difficult. 4 To become a good OO Programmer/Analyst, you must think in terms of OO ! – Otherwise you get traditional programs with an OO coating 19
Questions to be answered 4 Why is Object Orientation (OO) Popular? 4 Why is switching to OO not trivial 4 An Object Oriented Paradigm? 4 Overview of OO Concepts 4 Overview of OO Techniques 20
A New Paradigm. . . 4 What is a paradigm ? – a set of theories, standards, and methods that together represent a way of organising knowledge that is, a way of viewing the world. 4 In software development there are numerous ways of viewing the world. . . 21
Paradigms. . . 4 What are the major paradigms? Functional paradigm (Scheme, Lisp, . . . ) Logic paradigm (Prolog, . . . ) Imperative paradigm (Cobol, C, Lisp, Pascal, Fortran, . . . ) Object oriented paradigm (Smalltalk, Java, C++, . . . )New? Small languages and tools (Perl, Python, Tcl/Tk, . . . ) 22
Imperative Programming. . . 4 Imperative Programming is the ‘traditional’ model of computation – – Variables Procedures Functions Assignments, … 4 A set of procedures/functions acts upon memory – The processing unit is separated from this memory 23
Visualisation. . . proc_B causes a crash of proc_A (2) (1) proc_B (without knowing it) proc_A (3) E R U O I AV STAT BEH 24
Visualisation. (2) (1) Worked ‘fine’ for many years, but… (3) … systems become larger, so there was a R U IO V A need for something new BEH E STAT 25
Questions to be answered 4 Why is Object Orientation (OO) Popular? 4 Why is switching to OO not trivial 4 An Object Oriented Paradigm? 4 Overview of OO Concepts 4 Overview of OO Techniques 26
Object Orientation 4 Based on the principle of recursive design : – Everything is an object This includes basic datatypes : a. String, an. Integer, a. Float, . . . 4 Objects perform computation by making requests to each other : messages 4 An object has its own memory, which consists of other objects : state 27
Object Orientation 4 Every object is an instance of a class. A class groups similar objects (see later. . . ) 4 The reaction upon a message is described in a method 4 Information hiding is a very powerful aspect of OO 4 Classes can be organized into tree structures, called inheritance hierarchies (see later. . . ) 28
OO Concepts : Objects. . . 4 Everything is an object 4 All actions in OO are performed by agents called instances or objects Object = identity + state + behaviour Identity State a. Rectangle ulc: (10, 20) side 1: 50 side 2: 20 circumference( ) area( ) move. To(a. Point) Behaviour, Messages 29
Examples of Objects a. Traffic. Light an. Explorer a. Library a. Floppy a. Button a. Printer a. Sportman a. Cd. Rom 30
OO Concepts : Messages. . . 4 Objects perform computation by making requests from each other by sending nce() e r messages e f ircum c. e l ang a. Rect gle. area() my. Point) ( an 4 Actions are produced a. Rect gle. move. To n Recta a in response to messages 4 An object may accept a message – It will perform an action ze() i S e – The result of this action o h. get. S nderstood” e l g n a a. Rect sage not u is returned (an object) “Mes 31
Examples of Messages. . . set. Back. Color(a. Color) click() set. Focus() offline? () print(a. Document) get. Book(an. ISBN) get. All. Books() sort. By. Author(order) get. Average. Score() get. Age() display. Trophy. List() 32
Examples of Messages. . . refresh() select. Drive(a. Drive) window. Size(a. Size) switch. Color(a. Color) responding? () polymorphism ! start. Working() get. Contents() get. Label() delete. File(a. Filename) format() 33
OO Concepts : Messages Summary 4 Always sent to a receiver object 4 A message may include parameters (objects) necessary for performing the action 4 Message-send always returns a result (an object) 4 Only way to communicate with an object and have it perform actions Receiver Objects a. Rectangle. circumference() a. Rectangle. area() a. Rectangle. move. To(my. Point) a. Printer. print(my. File) an. Employee. set. Name(a. Name) Messages 34
OO Concepts : Methods. . . 4 Defines how to respond to a message 4 Selected via method lookup technique 4 Has name that is the same as message name 4 Is implemented as a sequence of executable statements 4 Returns an object as its result of execution a. Rectangle ulc: (10, 20) side 1: 50 side 2: 20 circumference( ) area( ) move. To(a. Point) Return Type Messagename Integer area() { return side 1 * side 2 } Integer circumference() { return (2*side 1)+(2*side 2)}. . . Method body 35
Messages vs Methods : What vs How. 4 What: Messages – Specify what behaviour objects are to perform – Details of how are left up to the receiver – State information only accessible through messages 4 How: Methods – Specify how operation is to be performed – Must have access to the objects’ internal state – Need detailed knowledge of internal state – Can manipulate internal state directly 36
OO Concepts : Classes. . . 4 “Factory” object for creating new objects of a certain type – These objects are referred to as instances of a class – (cfr. Cookie-cutter) 4 Every object must be an instance of a class 4 In “true” OO languages there exists a root class the class named Object Classname Rectangle a. Rectangle = Rectangle. new() Point my. Point = Point. new(10, 50) a. Rectangle. move. To(my. Point) Instancename 37
OO Concepts : Class Instances. 4 Instance = a particular occurrence of an object defined by a class 4 Each instance has its own value for each instance variable 4 All instances of a class share the same methods my. IBMStock IBM Inc. 3000 $ 78. 00 Instances Stock your. Apple. Stock Apple. Inc. 1000 $ 42. 00 company. Name numberof. Shares current. Price calculate. Value( ) calculate. Gainor. Loss( ) calculate. Tax. Liability( ) 38
OO Concepts : Object Encapsulation 4 Objects encapsulate state as a collection of instance variables 4 Objects encapsulate behaviour via methods invoked by messages External perspective What Message vs. vs. Internal perspective How Method 39
OO Concepts : Information Hiding 4 A user of a service provided by an object, s e c a f Inter only needs to know the set of messages that this object will accept. 4 The user doesn’t need to have any idea on i t a l how the actions performed in response ncapsu E to his request will be carried out. 4 Having accepted a message, an object is on i t a g responsible for carrying it out. Dele 40
Object Encapsulation 4 Technique for – Hiding implementation details – Protecting the state information of objects – Communicating/accessing via a uniform interface 4 Puts objects in control 4 Facilitates modularity, code reuse and maintenance Rectangle ulc: Point side 1: Integer Different Representation brc: Point side 2: Integer circumference area Same Interface ! area move. To: a. Point 41
Behaviour and Interpretation 4 Although different objects may accept the same message, the actions (behaviour) they perform will likely be different. 4 The determination of what behaviour to perform may be made at run-time, a form of late binding 42
Intermezzo. . . 4 Messages differ from traditional function calls in two very important aspects : – In a message there is a designated receiver that accepts the message. – The interpretation of the message may be different, depending upon the receiver – The object is in control of its own state. . . 43
Intermezzo. (2) (1) (3) BEH R U O I AV Encapsulation is a mechanism that solves this problem ! E STAT 44
Questions to be answered 4 Why is Object Orientation (OO) Popular? 4 Why is switching to OO not trivial 4 An Object Oriented Paradigm? 4 Overview of OO Concepts 4 Overview of OO Techniques 45
Class Hierarchies 4 Some classes are related to each other – Specialization principle – Generalization principle 4 Allows to : – Extend. . . – Refine. . . an existing class with your own version 46
Class Hierarchies : Example Explorer Storage. Medium label: String capacity: Integer Contents: File. Pool write(a. File) read(a. File) get. Contents( ) . . . Floppy. Disk capacity: 1440 Writeprotect: Boolean File. Pool. . . Cd. Rom capacity: 66500 joliet. Closed: Boolean format( ) delete( ) 47
Inheritance 4 Hierarchical definitions – Classes as units of sharing – Object’s state and behavioural description is broken into pieces – Promotes modularity and reusability Living Thing age Animal habitat 4 Inheritance – Child shares state/behaviour with parent – Child can add new state information – Child can selectively add and/or redefine behaviour Mammal pregnancy Human Being name 48
Overriding Behaviour 4 Subclasses can alter or override information inherited from parent classes : – All mammals give birth to live young – A platypus is an egg-laying mammal 49
Superclass/subclass Relationship 4 Superclass is the parent and subclass is a child 4 Subclasses specialise their superclass Living Thing Animal Reptile Mammal Plant Fish Tree Flower 50
Example of a Hierarchy Living Thing Rock Animal Reptile Mammal Human Being Dentist Florist Plant Cat Secretary Dog Platypus 51
Concrete vs. Abstract Classes 4 Abstract Class – Holds on to common characteristics shared by other classes – Not expected to have instances 4 Concrete Class – Contains complete Living Thing characterisation of actual Reptile objects – Expected to have instances Animal Mammal 52
Polymorphism. . . 4 Same message may be sent to different objects 4 Different receiver objects may respond differently to the same message. WOEF ! MEUH ! speak() 53
Polymorphism & Dynamic Binding 4 Mapping of messages to methods deferred until run-time 4 Allows for rapid incremental development without the need to recompile (in Smalltalk) 4 Most traditional languages do this at compile time (static binding) 4 Efficiency of dynamic binding very high. a. Rectangle a. Square a. Circle a. Graphic Area 54
Example: The Investment Manager 4 Many activities for each investment, e. g. , – Calculate current worth – Calculate tax liability 4 Nature of activity depends on: – Kind of investment (stock, bond, rental) – How long investment has been held – What’s happened during a particular period 55
Procedural Language Solution… 4 For each investment, define – Data Structures type: issue_name: int_rate: cur_price: pur_date: bond char* float date type: comp_name: cur_price: pur_date: type: location: rent_rate: pur_price pur_date: loan_bal: stock char* float date rental char* float date float State 56
Procedural Language Solution… 4 For each investment, define – Uniquely named Procedures float calc_stock_tax(stock) { result: float; result = (stock. pur_price stock. cur_price) * 0. 21; return(result); } Behaviour float calc_bond_tax(bond) { result: float; result = bond. pur_price * bond. int_rate) * 0. 21 return(result) } float calc_rental_tax(rental) { result: float; result = (rental. rent_rate * 12) * 0. 21; return(result) } 57
Procedural Language Solution… 4 For each activity, define: – Control (e. g. , case statements) to select proper set of procedures for handling each type of investment. calculate_taxes(investment_list): for each item in investment_list do begin index : = item. type; case index of Code to generate stock: calc_stock_tax(item); a tax report bond: calc_bond_tax(item); rental: calc_rental_tax(item); might look like: . . . end case end 58
A Simple OO Solution… 4 Have a unique class description for each kind of investment 4 Each investment object will have its own instance variables 4 Each investment has a calculate. Tax. Liability method Stock Bond Rental. Property company. Name numberof. Shares current. Price calculate. Value calculate. Gainor. Loss calculate. Tax. Liability issuer. Name interest. Rate purchase. Price calculate. Value calculate. Gainor. Loss calculate. Tax. Liability location rental. Rate purchase. Price calculate. Value calculate. Gainor. Loss calculate. Tax. Liability 59
A Simple OO Solution. Assume a list of current investments has already been generated. Code to generate a tax report might look like: (message) investment. List calculate. All. Taxes (method) investment. List do: [: each. Investment | each. Investment calculate. Tax. Liability] 60
Extending the Financial Investments Example Before Stocks Bonds After Rental Property Stocks Home Bonds Rental Property Mutual Funds Commercial Land 61
Revised Traditional Solution… 4 For each new kind of investment, define – New data structure(s) type: location: int_rate: pur_price pur_date: loan_bal: land char* float date float State type: comp_name: share_value: cur_price: pur_date: fund char* float date 62
Revised Traditional Solution… 4 For each new kind of investment, define – New uniquely named procedures float calc_fund_tax(fund) { result: float; result = ((fund. pur_price fund. cur_price) * fund. share_value ) * 0. 21; return(result) float calc_land_tax(land) } { result: float; result = (land. pur_price land. loan_bal) * 0. 21; return(result) } Behaviour 63
Revised Traditional Solution. 4 For each case, add a test for each new kind of investment Ensure that every case can handle the new types calculate_taxes(investment_list): for each item in investment_list do begin index : = item. type; case index of Code to generate stock: calc_stock_tax(item); a tax report bond: calc_bond_tax(item); rental: calc_rental_tax(item); might look like: fund: calc_fund_tax(item); land: calc_land_tax(item); . . . end case end 64
Revised OO Solution… » Create a new class description for each new kind of investment » Each new investment object will have its own instance variables » Each investment has a calculate. Tax. Liability method Mutual. Fund Commercial. Land company. Name share. Value current. Price calculate. Value calculate. Gainor. Loss calculate. Tax. Liability location interest. Rate purchase. Price calculate. Value calculate. Gainor. Loss calculate. Tax. Liability 65
Revised OO Solution. Because the individual objects know what to do, no changes are required Code to generate a tax report still looks like: (message) investment. List calculate. All. Taxes (method) investment. List do: [: each. Investment | each. Investment calculate. Tax. Liability] 66
Possible Hierarchy for Investments Object Investment Securities Investment Stock Bond Real Estate Investment Mutual Fund Commercial Property Raw Land 67
The Investment Manager Revisited Securities. Investment issuer. Name calculate. Price. Earnings Stock shares. Outstanding calculate. Volatility (calculate. Tax. Liability) Investment current. Value purchase. Price date. Purchased calculate. Gain. Or. Loss calculate. Tax. Liability calculate. Annual. Income Bond maturity. Date update. Rating (calculate. Tax. Liability) Home loan. Balance (calculate. Value) Securities. Investment location interest. Rate calculate. Value (calculate. Tax. Liability) Rental. Property rental. Rate (calculate. Value) (calculate. Tax. Liability) calculate. Depreciation 68
Summary. . . Object-Oriented Approach – Emphasises behavioural modeling – Is structured in terms of • Objects • Messages • Methods – Supports sharing through • Classes and instances • Class hierarchies 69
Summary. . . Object-Oriented Techniques » Are based on – Encapsulating data and procedures – Inheritance – Polymorphism – Dynamic binding » Facilitate – Modularity – Reusability and sharing – Extensibility and change (maintainability) 70
UNIT 1 Analysis & Design 71
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 72
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 73
ANALYSIS 4 Requirements Engineering (RE) 4 Creation, verification, validation of a conceptual specification : – problems, domain, future system 4 As complete as possible 4 Focus on real-world problems – What is the system supposed to do ? 74
Requirements Engineering 4 Input consists of many fuzzy informal statements of requirements – Statements come from the future users of the system 4 An agreement must be reached – With all the stakeholders 4 Four fundamental RE Processes : – Requirements elicitation, specification, verification, validation 75
Fundamental RE Processes 4 Requirements elicitation – Gain relevant knowledge about the problem and its context – Could/should be an ongoing process running parallel with other RE processes – Results in an informal requirements document • informally specified in natural language 76
How to Elicit Knowledge. . . Scenario based Analysis Objective and Reuse Goal Analysis Task Form Analysis … From Users 77
How to Elicit Knowledge. . . 4 From users – interviews, questionnaires, brainstorming sessions, … – Problems experienced : • • Users that do not have a clear idea of what they want Users that do not agree on what they want Users that are not able to describe what they want Users use domain oriented terminology, analysts use computer oriented language • Users that simply refuse to cooperate or participate 78
How to Elicit Knowledge. . . 4 Objective and Goal Analysis – Ask and question the reasons why a system needs to be built 4 Task Analysis – How do the users do their job? • Activities they perform and the structure in which they perform them • What kind of knowledge is required to perform the activity 79
How to Elicit Knowledge. 4 Scenario-based Analysis – Make use of active ‘story telling’ sessions 4 Form Analysis – Listings, official documents, … • Less ambiguous, less inconsistent and structured 4 Reuse – Do not reinvent the wheel over and over again 80
Fundamental RE Processes 4 Requirements Specification – Analyze, assimilate, synthesize, organize knowledge from the requirements document – Describe the problem formally by creating models – Different views of the problem may exist • Try to reach an agreement – Results in a requirements specification 81
What Aspects must be Modeled 4 3 main requirements should be modeled : – Enterprise requirements • Allows to delimit the scope of investigation • Provides a context and justification for the system to be built • Considers organizational structures, activities, processes, products, agents and work roles – Functional requirements • What is the system intended to do 82
What Aspects must be Modeled – Non functional requirements • Issues like performance, external interfaces, design constraints, standards, quality attributes, security, . . . 83
Requirements Specification Properties 4 Requirements Verification – Check wether the models have certain properties • Communicability – Dual nature ! • Implementation Independency • Completeness – To a certain degree 84
Requirements Specification Properties • Feasibility – benefits vs costs • Consistency – All conflicts must be resolved • Verifiability – Properties of the system should be specified in a measurable way • Maintainability – Changes should be easily incorporatable 85
Requirements Specification Properties • Validity – External consistency » Reach an agreement between what is stated in the model and what is true in the problem domain – Non-ambiguity » A req. cannot be interpreted in more than one way – Minimality » No over-specification – Completeness » No omission of essential elements 86
Importance of RE 4 Wrong decisions, misunderstandings made in this phase have a major impact ! 4 RE process provides a foundation by : – Enforcing users to consider req. carefully – Aims at an as correct and complete as possible specification of the problem and domain – Bringing users and developers in agreement – Acting as a contractual agreement – Basis for managerial activities : cost, time, . . . 87
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 88
DESIGN 4 Detailed specifications that describe the intended form of implementation – For all SW components – For all relationships between these components • How do they fit together? 4 Specification of SW architecture 4 Focus on computerized solutions – A blue-print of how to construct the system 89
Features of Good Design 4 Completeness and correctness – Fitness for purpose 4 Robustness – Stable against changes 4 Maintainability 4 Reusability 4 Modularity 4 Simplicity. . . 90
Main Contributions. . . 4 Further refinement of aspects identified in analysis phase – move seamlessly to actual implementation 4 Adaptation of system to actual implementation environment – Contrast to ideal world of analysis • How to incorporate existing legacy systems, available HW and SW, performance, people, . . . 91
Main Contributions. 4 Additional validations of analysis results – Maybe we were too idealistic – Maybe the problem is not implementable as is? 4 Result = A design model 92
A Possible System Architecture Reference Model 4 6 subsystems (Components) : – Problem Domain, Human Interaction, External Interface, Data Management, Task Management, Utility Services 93
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 94
IMPLEMENTATION 4 Last creative phase of SW development 4 Creation of all : – HW and SW components – Documentation of the system – User documentation – Organizational structures –… 4 ‘Results’ into an executable system. . . 95
Main Implementation Issues. . . 4 Programming languages – Often not free to choose – Each have their own weaknesses and strengths 4 Increased complexity – Often leads to patchwork • e. g. unsupported features • Or undocumented features 4 Increased quality requirements 96
Main Implementation Issues. 4 Reduction of development time 4 Evolving nature of systems – Written today, outdated tomorrow. 97
How to Facilitate this Phase 4 Two main approaches – Reuse of programming code • The reapplication of a variety of kinds of knowledge about one system to another similar system in order to reduce the effort of development and maintenance of that other system. – In majority of projects it remains hype, however OO. . . – Code generation • Many CASE tools offer this feature – Results remain dubious. 98
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 99
TESTING 4 Make sure a system contains as few as possible errors (0), before deliverance. 4 Focus on : – Validation • Develop the right product – Verification • Develop the product right – Qualification • Develop right 100
Several Kinds of Tests. . . 4 Unit test – Test individual SW components seperately – Focus on small pieces of code • e. g. classes in OO 4 Integration test – Test the method, procedure, function interfaces of SW components • Can they communicate with each other ? • Is the protocol respected ? 101
Several Kinds of Tests. 4 System test – Compare the SW system to original goals and objectives – Test the capability of the system to satisfy performance, security, usability, and stability 4 Acceptation test – Let the user test the system • Does the system perform as expected • Is the user documentation understood 102
Phases vs. Tests Analysis Acceptation Test Requirements Elicitation System Test Design Integration Test Implementation Unit Test 103
Main Development Phases Problem Analysis Design Implementation Testing Exploitation Maintenance 104
EXPLOITATION and MAINTENANCE 4 The system is built, the real work starts 4 3 main categories – Corrective – Adaptive – Perfective 4 Sometimes 50 % of total system cost ! 4 Sometimes better to restart building a system. . . 105
Summary Problem Analysis Design Implementation Testing Exploitation Maintenance 106
Development Strategies. . . 4 Different ways to execute development phases 4 Linkage of phases in a Life cycle • Define the actions of each phase • Define the deliverables of each phase • Define the transition from one phase into another 4 In early days of computing there was no need for a strategy – Simply encode the problem and test CRISIS 107
Development Strategies. 4 Two main directions – Linear vs. Iterative development – Incremental development 4 Well-known strategies – Waterfall model – Prototyping approach – Spiral model 108
Linear vs. Iterative development 4 Linear direction – Phase based – Each phase carried out once • After a phase is concluded you never enter it again – No iteration, so no mistakes ? ? ? 4 Iterative direction – Allows (parts of) a phase to be carried out more than once – Commonly accepted 109
Incremental Development. . . 4 Partial implementation (PI) instead of total system at one go 4 When PI turns out fine – Add more functionality – Add increased performance, … 4 But how many units of incremental delivery are needed? – Reach agreement before starting ! 110
Incremental Development. 4 Main decisions to be made : – What is subject to incrementation • The product as a whole or parts of it? – What is subject to iteration • Phases as a whole or steps from phases? 111
The Waterfall Model. . . 112
The Waterfall Model. . . 4 Interaction between subsequent phases 4 Includes iteration and feedback – Feedback loops allow modification 4 Each phase is completed by documenting the achievements 113
The Waterfall Model. . . 4 Main benefits of introduction – Systems are specified before construction – System components are designed before encoded – Tends to ease project management • Well-defined milestones – Facilitates maintenance • Required documentation per phase 114
The Waterfall Model. 4 Main criticism : – Too strict seperation of phases • Often very artificial – An executable SW version appears at the end of the project ! • Too late for major changes • Could be solved by the notion of prototyping 115
Derivative : Fountain Model Maintenance Program Use Further Development Unit Testing Coding Program Design System Design Software Requirements Specification User Requirements Specification Requirements Analysis 116
Prototyping Approach. . . 4 What is a prototype ? – An executable model of (parts of) a SW system, which emphasizes specific aspects. 4 High degree of user participation 4 Concrete representation of user requirements 4 Very useful whenever requirements are unstable or uncertain 117
Prototyping Approach. . . 4 Throwaway Prototyping – Makes use of prototypes early in development to clarify poorly understood parts 4 Iterative/Evolutionary Prototyping – The initial prototype provides an overall framework for the total system 118
Prototyping Approach. 4 Main benefits : – Faster development time – Resulting system is easier to use and to learn 4 But be careful : – Working out specific details too early • Most of the time on user demand – There is a danger that the final system will still be a prototype 4 Smalltalk is well suited for making prototypes 119
State of the Art 4 Object Modeling Technique (OMT) 4 Booch Method (OOD) 4 Object-Oriented Software Engineering (OOSE) 4 Kirsten Iteration, Selection and Sequence Method (KISS) 4 Method for Conceptual Modeling (MCM) 4 Object Behaviour Analysis (OBA) 4 Shlaer/Mellor Method 4 Yourdon Method 120
State of the Art 4 Object Modeling Technique (OMT) e s e h t f o 4 Booch Method (OOD) t s e b e h Engineering (OOSE) t f o 4 Object-Oriented Software n o i t a n i = and Sequence Method b m 4 Kirsten Iteration, Selection o C (KISS) UML 4 Method for Conceptual Modeling (MCM) 4 Object Behaviour Analysis (OBA) 4 Shlaer/Mellor Method 4 Yourdon Method 121
- Slides: 121