� ������������������������������������������������ Chapter 1: Programming Principles Abstraction and Information Hiding � Abstraction � Object Oriented Analysis and Design � provide an easier higher-level interface to mask � Abstraction and information hiding possibly complex low-level details � Object oriented programming principles � functional abstraction � Unified Modeling Language � separates the purpose of a module from its implementation � Software life-cycle models � specifications for each module are written before implementation � Key programming issues � data abstraction � focuses on the operations of data, not on the implementation of the operations EECS 268 Programming II 1-1 EECS 268 Programming II 1-2 Abstraction and Information Hiding Abstraction and Information Hiding � Abstract data type (ADT) � Information hiding � a collection of data and a set of operations on the � hide details within a module data � ensure that no other module can tamper with these hidden details their implementations or how data is stored, if � public view of a module ��������������������������������������� � described by its specifications � Data structure � private view of a module � construct that is defined within a programming � implementation details that the specifications should not describe language to store a collection of data EECS 268 Programming II 1-3 EECS 268 Programming II 1-4
Principles of Object-Oriented Principles of Object-Oriented Programming (OOP) Programming (OOP) � Object-oriented languages enable us to build � Three principles of OOP classes of objects � Encapsulation � objects combine data and operations � A class combines � hides inner details � attributes of objects of a single type � Inheritance � typically data � classes can inherit properties from other classes � called data members � existing classes can be reused � behaviors (operations) � Polymorphism � typically operate on the data � objects can determine appropriate operations at � called methods or member functions execution time EECS 268 Programming II 1-5 EECS 268 Programming II 1-6 Object-Oriented Analysis & Design Object-Oriented Analysis & Design � A team of programmers for a large software � Analysis � Process to develop development project requires � an understanding of the problem � an overall plan � the requirements of a solution � organization � what a solution must be and do, and not how to design or implement it � communication � Object-oriented analysis (OOA) � Problem solving � expresses an understanding of the problem and the � understanding the problem statement requirements of a solution in terms of objects � design a conceptual solution � objects represent real-world objects, software � implement (code) the solution systems, ideas � OOA/D is a process for problem solving. � OOA describes objects and their interactions among one another EECS 268 Programming II 1-7 EECS 268 Programming II 1-8
Object-Oriented Analysis & Design Applying the UML to OOA/D � Unified Modeling Language (UML) � Object-oriented design � tool for exploration and communication during � expresses an understanding of a solution that the design of a solution fulfills the requirements discovered during OOA � models a problem domain in terms of objects � describes a solution in terms of independently of a programming language � software objects, and object collaborations � visually represents object-oriented solutions as � objects collaborate when they send messages diagrams � creates one or more models of a solution � enables members of a programming team to � some emphasize interactions among objects communicate visually with one another and gain a common understanding of the system being built � others emphasize relationships among objects EECS 268 Programming II 1-9 EECS 268 Programming II 1-10 Applying the UML to OOA/D Applying the UML to OOA/D � An example of a main success scenario � UML use case for OOA � customer asks to withdraw money from a bank � A set of textual scenarios (stories) of the solution account � e ����������������������������������������������������������� � bank identifies and authenticates customer circumstances from the perspective of the user � bank gets account type, account number, and � focus on the responsibilities of the system to meeting a withdrawal amount from customer ������������ � bank verifies that account balance is greater than � main success scenario (happy path): interaction between user and system when all goes well withdrawal amount � alternate scenarios: interaction between user and system � bank generates receipt for the transaction under exceptional circumstances � bank counts out the correct amount of money for � Find noteworthy objects, attributes, and associations customer within the scenarios � customer leaves bank EECS 268 Programming II 1-11 EECS 268 Programming II 1-12
Applying the UML to OOA/D Applying the UML to OOA/D � An example of an alternate scenario � customer asks to withdraw money from a bank account � bank identifies, but fails to authenticate customer � ���������������������������������������������� � customer leaves bank Figure 1-2 Sequence diagram for the main success scenario EECS 268 Programming II 1-13 EECS 268 Programming II 1-14 Applying the UML to OOA/D Applying the UML to OOA/D � UML class (static) diagram � Represents a conceptual model of a class of objects in a language-independent way � Shows the name, attributes, and operations of a class � Shows how multiple classes are related to one another Figure 1-3 Sequence diagram showing the creation of a new object EECS 268 Programming II 1-15 EECS 268 Programming II 1-16
� ������������������������������������������������������������ Applying the UML to OOA/D Applying the UML to OOA/D Figure 1-4 Three possible class diagrams for a class of banks Figure 1-5 A UML class diagram of a banking system EECS 268 Programming II 1-17 EECS 268 Programming II 1-18 Applying the UML to OOA/D The Software Life Cycle � Class relationships � Describes phases of s/w development from � association conception, deployment, replacement to deletion � classes know about each other (Bank � Customer classes) � Iterative and Evolutionary Development � aggregation (Containment) � One class contains instance of another class (Bank � Account � many short, fixed-length iterations build on the classes) previous iteration � lifetime of the containing and contained may be the same � iteration cycles through analysis, design, (composition) implementation, testing, and integration of a small � generalization portion of the problem domain � indicates a family of classes related by inheritance � early iterations create the core of the system; further ������������ iterations build on that core EECS 268 Programming II 1-19 EECS 268 Programming II 1-20
Rational Unified Process (RUP) Software Life Cycle Development Phases � Rational Unified Process (RUP) Development � RUP uses the OOA/D tools � four development phases � Inception: feasibility study, project vision, time/cost estimates � Elaboration: refinement of project vision, time/cost estimates, and system requirements; development of core system � Construction: iterative development of remaining system � Transition: testing and deployment of the system Figure 1-8 Relative amounts of work done in each development phase EECS 268 Programming II 1-21 EECS 268 Programming II 1-22 Software Life Cycle Achieving a Better Solution � Waterfall Method of Development � Analysis and design improve solutions � develops a solution through sequential phases � Cohesion � perform one well-defined task � requirements analysis, design, implementation, testing, � for self-documenting, easy-to-understand code deployment � easy to reuse in other software projects � hard to correctly specify a system without early � easy to revise or correct feedback � Robust � less likely to be affected by change; � wrong analysis leads to wrong solution performs well under unusual conditions � outdated (less used) � promotes low coupling � do not impose this method on RUP development EECS 268 Programming II 1-23 EECS 268 Programming II 1-24
Recommend
More recommend
