Lecture Notes in object-oriented analysis and design

object oriented analysis and design case study examples. object oriented analysis and design important questions. object oriented analysis and design in software engineering pdf free download
Dr.DouglasPatton Profile Pic
Dr.DouglasPatton,United States,Teacher
Published Date:26-07-2017
Your Website URL(Optional)
Comment
Lecture Notes in OBJECT-ORIENTED ANALYSIS AND DESIGN Walid S. Saba School of Computer Science University of Windsor Copyright  1999, 2000 Walid S. Saba W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 4 Introduction Designing software for large applications is a very complex task. It could arguably be said that there is no limit to how complex software design could get. The reason for this is that we generally design software to model some real-world phenomenon. The more realistic we aim to make our model the more complex the design, since in general real-world phenomena can be very complex. Take, for example, the modeling of activities on the stock market. To accurately represent all the parameters (variables) that might affect the behavior of a certain stock a system must take into account various statistical data (trends), as well as a complicated set of interrelationships between various pieces of data (for example, political instability in the middle east might affect the price of oil, which in turn might affect the inflation rate, which again, incidentally, might affect the price of oil.) How can such complex relationships be modeled? There are several reasons for the complexity here. The main source of the complexity in the modeling of the stock market is the fact that this model involves two distinct set of rules: (i) a set of analytic rules that can be well specified by expert actuaries and statisticians; and (ii) a set of commonsense rules and a number of heuristics that represent the ”knowledge” of some experts. One challenge here is how to ultimately separate these two distinct sets of rules in the software, since the latter is a very dynamic set that could change on a daily basis. If modeling the stock market is not complex enough, imagine the complexities involved in modeling the cognitive and reasoning capabilities of humans in building intelligent machines. Researchers in artificial intelligence (AI) are trying to emulate human perceptual, language, and reasoning capabilities. In addition to the conceptual breakthroughs, there are various computational challenges that arise when building such systems. The fact that the logic of some applications can be very complex is one source of complexity in software design. The other source of complexity comes from the fact that software in the end is executed on machines and thus applications must be written with a computational environment in mind. While some of the constraints of the computational environment are not (and should not be) considered at the analysis phase, time and memory constraints, as well as issues that relate to concurrency, whether the system needs to be dynamic or static, add another level of complexity. The point of all of this is that building large applications is a complex task and like engineers in other disciplines, software engineers need a good set of tools that can aid the analysis, the design and ultimately the implementation process. Indeed, over the years a number of programming tools, languages and paradigms where suggested. The aim of each paradigm was to help improve on one or more of the following: • Rapid application development (RAD) • Maintainability • Performance • Reuse Among these, the most visible improvement is in the number of RAD tools that exist today. However, in many cases the tradeoff in using these tools is in performance W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 5 KNOW THE TECHNOLOGY • As a software engineer, how do you make a case for a certain technology, T? Must say, T can help us … as opposed to, T … build re-usable code supports inheritance build highly maintainable code supports data abstraction build concise and well-structured code is polymorphic, has templates build cross platform software compiles to a virtual machine modify online systems is dynamic build efficient code is multi-threaded in RAD and prototyping is high-level, is declarative ? is strongly-typed ? is reflective ? is higher-order etc. etc. • A manager might not care if a certain language is dynamic, but you should, if you had to build a system the behavior (logic) of which might have to be updated at run-time. • If you can not describe a feature (say, inheritance, polymorphism, etc.) without any reference to a specific programming language, then you probably do not fully understand (appreciate the value of) this feature. W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 6 DESIGN TRADEOFFS • There is no ‘good design’ in the absolute sense. A design can only be measured against some context. • Given a set of requirements and a number of environmental constraints, one can judge a design. • Any design, therefore, is about making tradeoffs. • Some common (and important) design tradeoffs: ¾ Maintainability vs. Performance ¾ Time vs. Space (Storage) Complexity ¾ Static (Compiled) vs. Dynamic Environments ¾ Others requirements that might effect design decisions include: open system, real-time, fault-tolerance, distributed vs. centralized control, etc. Can anyone (formally) prove that there is always a tradeoff between highly intuitive/maintainable and highly efficient code? Can we not in theory/principle maximize both? Why or why not? W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 7 ANALYSIS VS. DESIGN • S/W construction is an iterative process. • The analysis and design tasks are not different, except for the level of detail. This view minimizes the gap between “what” the system must do and “how” it is done • Thus, analysis and design are best thought of as two special states in a continuum. • In the early stages we should pay little attention to implementation details. The final stage (final design) should be “the realization of the model within a certain (computing) environment.” • In general the model at level n should be more stable than the model at level n+1. For example, early analysis is not so sensitive to change as a detailed design would be if the programming language, database or other environmental variables changed. 1 5 2 4 3 2 3 1 1 Analysis 2 Design 4 3 Coding 4 Testing 5 5 Maintenance W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 8 WHY DIFFERENT PROGRAMMING PARADIGMS? program=data+control data control / logic • • • • Different paradigms interpret the ‘program=data+control’ equation differently. • Some paradigms try to achieve re-use by building re-usable data objects, some by building re-usable modules. • program = data + control (logic) ⇒ generic(program) = generic(data + logic) Therefore, to build generic (re-usable) programs we can generalize the data, the control, or, of course, both. • Generic data objects are attained via data abstraction • Generic modules are attained via functional abstraction W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 9 WHY DIFFERENT PROGRAMMING PARADIGMS? f () mainFunc() Obj Obj 1 2 g() f () Obj Obj 4 3 g() • Different paradigms interpret the ‘program=data+control’ equation differently when building small modules. • There are two competing classes of paradigms: (i) data- centric and (ii) control-centric. • In the data-centric model the building blocks (modules) are data objects, and control is implemented as various services that the data objects promise to provide to clients. • In the control-centric model data flows in and out of small modules (functions, procedures, rules, etc. – see below) that are glued together to achieve a larger task. • In this sense the object-oriented paradigm does stand on its own as a completely different way of structuring (building) programs. W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 10 WHAT’S NEW IN THE OO PARADIGM? f () Obj Obj mainFunc() 1 2 g() f() Obj Obj 4 3 () g • The procedural, functional, logic, etc programming paradigms differ substantially in how control is attained: function composition, procedure calls, rule-chaining, etc. (they also differ in whether or not they are: strongly-typed, high-order, reflective, static/dynamic, polymorphic, lazy/strict, multithreaded, etc.) program and data control or triggers messages functions procedures rules • BUT, as far as the general philosophy of program design, they all belong to the same class, i.e., they are all control- centric (as opposed to data-centric) • In the OO paradigm we structure our programs around data objects and control (intelligence) is distributed as a set of services that each data object promises to provide. W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 11 SO WHAT IS THE SOFTWARE CRISIS? • RAD (Rapid Application Development) ¾ Most programming paradigms emphasize the ease of software development ¾ This technology has advanced tremendously (we can now develop a prototype within hours and with minimal amount of coding.) • Maintainability ¾ S/W Maintenance is more costly than S/W development ¾ Maximizing cohesion of and minimizing coupling between modules is the key to building highly maintainable code ¾ Different paradigms approach this problem in various ways. • Re-use ¾ Design block-box modules (software chips?) ¾ Can we ever build generic (re-usable) business objects? ¾ Is there more hope in building generic (re-usable) functions? W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 12 TRACEABILITY AND THE MAINTENANCE PROBLEM • Traceability: where does (should) a certain piece of logic reside? • If a module implements too many business rules, how do we update some without effecting the others? • Maximizing cohesion of and minimizing coupling between modules is the key to highly maintainable code • Clearly, to simplify the maintenance task, we must do a good job of distributing the intelligence across the system at design time. These ideas are not entirely new User Interface • 3-tier architecture: UI, Control, Data (Ivar Jacobson) Business Logic • Multi-tier architecture: Control must System− Related also be cleanly separated into two important levels: application and business logic. Data Layer • In large systems the challenge is in the middle layer. W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 13 THE OBJECT-ORIENTED DESIGN PHILOSOPHY • OO is NOT about polymorphism, encapsulation, inheritance, etc. OO is a new strategy for distributing intelligence across the system so as to maximize cohesion and minimize coupling By distributing intelligence across the system in a data-centric fashion, we implicitly build highly cohesive (& thus re-usable) modules, without introducing unnecessary coupling. • The question now is how do we best distribute intelligence across the system? This is the object- oriented design problem W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 14 THE OBJECT-ORIENTED DESIGN PHILOSOPHY • In structured programming there is a centralized control. ‘main’ controls the sequencing (and the control flow) and owns all external and global data/information. • In OOP, there is no centralized control. Ideally, all objects are created equal and control is an interaction between objects that collaborate to achieve a certain functionality. • A First Example. An ATM machine. Main() while ( true ) acctNo = getAcctNo(); pinNo = getPIN(); if ( notValid(pinNo,acctNo) ) exit(CODE); case (choice) of 1: deposit(amt,acctNo); 2: withdraw(amt,acctNo); 3: return checkBalance(acctNo); void withdraw(amt,acctNo) b = checkBalance(acctNo); if ( b = amt ) updateBalance(SUB,amt,acctNo); giveMoney(amt); W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 15 THE OBJECT-ORIENTED DESIGN PHILOSOPHY Customer Name PIN AcctNo Etc… ATM EnterPIN() Bank MakeSelection() Branch EnterAmount() ListAcceptedCards Etc… LogIn() Account GiveMoney() Number TakeMoney() Type DisplayBalance() Balance PrintBalance() Etc… private DisplayChoices() Withdraw() private HandleSelection() Deposit() Etc… GetBalance() SetBalance() Etc… A FIRST LOOK • Each object maintains its relevant data (encapsulation) • Each object publishes a public interface that implements its agreed- upon responsibilities (services it promises to provide to clients). • Hidden (bookkeeping or control) functions need not be exposed and are defined as private. • Objects may provide a service but not have the implementation (these services are provided by delegation). For example, the ATM object promises to respond to a printBlanace()message. The ATM object will most likely delegate this function to a contained object (a printer). This detail should be hidden from the user. (more on this later) • Can any of the above objects be re-used in another application? W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 16 EXERCISES FOR PART I • A typical telecom company has many systems, some real-time telephony systems that automate dialing, switching, etc. and some backend systems that are used for network management, etc. In the former performance is the main requirement, while in the latter it is not as crucial. What kind of design tradeoffs you think the designers of these systems have to make? • Suggest examples where a dynamic environment is more suitable than a static (compiled) environment. • Discuss the tradeoff between maintainability and performance. Think of the two extremes (say assembly language vs. very high-level declarative languages.) • Give examples of details that should not be discussed in the analysis phase, but should be left to design. Why? • Should a programming language or the computing environment be taken into consideration when in the design phase? Why, or why not? • What makes the maintenance problem so critical? Is that what the ‘software crisis’ is? Or is development the main challenge? Discuss in relation to very complex systems. • Any program satisfies ‘program=control+data’. To build generic programs, therefore, we can generalize the data, control (functions), or both. Which of the two (data and control) is easier to generalize? Discuss and give some examples of business objects and rules/logic. • What are good examples of generic data objects that are used everyday by software developers. What are good examples of generic modules (functions)? W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 17 EXERCISES FOR PART I (CONT’D) • Define/describe without referring to any specific programming language, and discuss with examples the advantages of each of the following: - Inheritance - polymorphism - data abstraction - higher-order - reflection • How is the object-oriented paradigm different from all the other paradigms with respect to program design? Discuss. • In the SW life cycle, programming paradigms often make promises regarding ease of development (RAD), and/or maintainability. Which paradigms facilitate RAD and which make promises regarding maintainability? In your opinion, where is the real problem in SW engineering, and where do you think OO stands on that? • What is ‘traceability’? How is it related to maintainability? • What are multi-tier architectures? Why are they useful? How is all of this related to maintainability and re-use? • The main idea behind OO is a better distribution of logic across the system to minimize coupling and maximize cohesion. This produces highly maintainable and re-usable code. How is that? Discuss. • How do structured (procedural) programs lend themselves to centralized control while object-oriented programs are more easily constructed with distributed control? How does that relate to coupling, cohesion, and maintainability? • Describe the data abstractions and functional abstractions that are needed to write a sort function that sorts data of any type and in any order. (can this be achieved with one kind of abstraction only?) W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 18 ASSIGNMENT 1 1. A typical telecom company has many systems, some real-time telephony systems that automate dialing, switching, etc. and some backend systems that are used for network management, etc. In the former performance is the main requirement, while in the latter it is not as crucial. What kind of design tradeoffs you think the designers of these systems have to make? 2. Suggest examples where a dynamic environment is more suitable than a static (compiled) environment. 3. Discuss the tradeoff between maintainability and performance. Think of the two extremes (say assembly language vs. very high-level declarative languages.) 4. Give examples of details that should not be discussed in the analysis phase, but should be left to design. Why? 5. Should a programming language or the computing environment be taken into consideration when in the design phase? Why, or why not? 6. What makes the maintenance problem so critical? Is that what the software crisis is? Or is development the main challenge? Discuss in relation to very complex systems. 7. Any program satisfies ’program=control+data’. To build generic programs, therefore, we can generalize the data, control (functions), or both. Which of the two (data and control) is easier to generalize? Discuss and give some examples of business objects and rules/logic. 8. What are good examples of generic data objects that are used everyday by software developers. What are good examples of generic modules (functions)? 9. Define/describe without referring to any specific programming language, and discuss with examples the advantages of each of the following: a. Inheritance- polymorphism b. data abstraction - higher-order languages c. reflection- dynamic languages 10. How is the object-oriented paradigm different from all the other paradigms with respect to program design? Discuss. 11. In the SW life cycle, programming paradigms often make promises regarding ease of development (RAD), and/or maintainability. Which paradigms facilitate RAD and which make promises regarding maintainability? In your opinion, where is the real problem in SW engineering, and where do you think OO stands on that? 12. What is ’traceability’? How is it related to maintainability? 13. What are multi-tier architectures? Why are they useful? How is all of this related to maintainability and re-use? 14. The main idea behind OO is a better distribution of logic across the system to minimize coupling and maximize cohesion. This produces highly maintainable and re-usable code. How is that? 15. How do structured (procedural) programs lend themselves to centralized control while object- oriented programs are more easily constructed with distributed control? How does that relate to coupling, cohesion, and maintainability? 16. Describe the data abstractions and functional abstractions that are needed to write a sort function that sorts data of any type and in any order. (can this be achieved with one kind of abstraction only?) W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 19 FOUNDATIONS OF THE OBJECT MODEL Abstract Data Types (ADT) • The basic idea is to design a data structure with a certain expected behavior the details of which are hidden from its users. • For example, a Stack object might be implemented in so many ways, as an array, a list, etc. All users need to know is that the operations they expect, namely Push(), Pop(),isEmpty()and isFull()are supported and they behave as expected. Information Hiding (Encapsulation) • Users of a class should not be concerned with internal representation of data members or implementation details of services. If any of these have changed, users of the class should not be effected. ON HIDING DETAILS…. Can you provide the services/behavior of a queue if you only had stacks? class myQueue private: Stack stack1; private: Stack stack2; Push(Object e) if ( not stack1.isFull() ) stack1.Push(e); return; else CAN-NOT-ADD-ELEMENTS-TO-QUEUE; Object Pop() if ( not stack2.isEmpty() ) return stack2.Pop(); if ( stack1.isEmpty() ) return QUEUE-EMPTY; while ( (not stack1.isEmpty()) && (not stack2.isFull()) ) stack2.Push( stack1.Pop() ); stack2.Pop(); Boolean IsEmpty() return stack1.isEmpty(); Boolean IsFull() return stack2.isFull(); W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 20 THE BUILDING BLOCKS OF THE OBJECT MODEL • Classes A class is a data abstraction of some concept/entity (physical or abstract). The abstraction is meant to capture the characteristics (properties/attributes) and behavior common to all instances of the class. For example, all ‘cars’ in the real world could be modeled by the following data abstraction: Car Make Model All cars have a make, a model, a year of make and Year a color. Also, we must be able to Start(), Drive(), Color ChangeSpeed(), Brake(), and Stop() all cars. Start() Drive() ChangeSpeed() Brake() W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 21 GENERALIZATION (DATA ABSTRACTION) • When we recognize commonality in characteristics and behavior we abstract these commonalties out - we generalize. For example, what we assumed on ‘Car’ applies to all vehicles. Or does it? • Note that as we go down in the hierarchy concepts become more specifically defined. As we go up in the hierarchy, concepts become more abstract. Can you visualize a picture of the general concept of vehicle? What about the concept ‘man-made-thing’? • Unlike classes, which are mere abstractions, objects are unique instances of classes and are assumed to represent actual entities (physical or abstract). Objects have: ¾ Identity ¾ State ¾ Behavior W. SABA OBJECT-ORIENTED ANALYSIS AND DESIGN 22 CLASS VS. INSTANCE • Objects (instances of classes) have attributes that can take on various values from a given domain/type. • We can also specify class attributes: attributes who’s value is shared by all instances of a class. In a sense, a class attribute is a global variable within a single domain (concept space). • These class attributes are useful, as they can be used to enforce some important semantic constraints. • We can also define class-scope operations. • In languages like C++ and Java class variables are implemented as static data members. • In languages like Smalltalk and CLOS (Common LISP Object System) there are class variables (members) and instance variables (members) that are defined explicitly. Meta classes (abstract classes) • Classes that are defined as templates to other classes are called meta classes (or abstract) classes. • These classes can not be instantiated but are sub-typed. • The value of these classes is that they enforce a certain prototype (structure) and behavior (methods) that all their subtypes must support.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.