§ Principals of Object Orientation § OO Analysis § Modeling with UML – UML Views • User model view • Structural view • Behavioral view • Implementation view • Environment view CS 585 Functional View Static View Dynamic View 1
Principals of Object Orientation CS 585 2
What is an Object? § A thing § A Visible Thing § It has: – Identity – Behavior • What the object do and what can be done to it – State – this includes • static properties and dynamic values of these properties § Structure and behavior of similar objects are defined in a common CLASS. CS 585 3
What is an Object § Behavior of objects is achieved via its – Operations and – Methods. § The state of an object is realized thought the contents of its data. § Objects can communicate via messaging protocols CS 585 4
Object Behavior - Object Life Cycle Initialize Object Wait for Request Handle Request Terminate Object CS 585 5
Principals of OO - Abstraction § Abstraction – Denotes the essential characteristics of an object that distinguishes it from all kinds of objects. • What does the object do without any implication on how does it do it – A software object is an abstraction • A representation of something in the real word like a student, a book, … CS 585 6
Principals of OO - Encapsulation § Encapsulation – The process of Compartmentalizing the elements of an object that constitute its structure and behavior • Data hiding • Localize design decisions – What are the encapsulated elements? • Information that describes the object (the things an object know about itself) – Encapsulation – No of pages, cover type, ISBN, and other Book information State, the object’s current condition (or state) • Behavior – – What the object can do (register, drop etc. ) What can be done to it (a pencil object can Write!!) CS 585 7
Principals of OO - Encapsulation § Encapsulation – What you need to know to use the object • The interface – What you need to know in order to make the object work properly • Mechanism to respond to the interface, THE IMPLEMENATION FOR EACH INTERFACE § Example – Driving a car! • You need to know the ignition, steering, brake, and gas pedal • No need to know about the mechanics of the engine, spark plugs, etc. CS 585 8
Principals of OO § Modularity – OO is different from Structured Paradigm – In Structured Paradigm module and function are the same – In OO Paradigm Classes and objects are the lowest form of Modularity. • A module could have multiple classes CS 585 9
Principals of OO § Hierarchy – Ranking of ordering of abstraction § Inheritance (is a) – The relationship between classes • One class share the structure and behavior of one or more classes • Generalization and Specialization CS 585 10
Inheritance Class: Furniture Object: Chair Cost Dimensions Weight Color Cost Chair inherits all attributes and operations of class Furniture Buy Dimensions Weight Color Buy Sell CS 585 11
Principals of OO § Polymorphism – The same operation may behave differently on different classes. • Example + sign – When an object is substituted with one of its children at run time • (The is-a relationship) – Overloading of operations • Same operation with different signatures CS 585 12
Principals of OO § Identifying Classes – External Entities (devices, people) – Things (reports, forms, Features, Estimates) – Occurrences or Events (Moving) – Roles (Mangers, Engineers, Group, Team) – Places (Loading dock, Shipping Floor) – Structures(Computers) CS 585 13
OO Analysis CS 585 14
OO Modeling § OO has its own Modeling Techniques § UML – Unified Modeling Language – Grady Booch Method – James Rumbaugh Method – Ivar Jacobson Method CS 585 15
OO Modeling § Grady Booch Method – Micro Development Process • Defines a set of analysis tasks that are re-applied in the Macro process • Identifies classes, objects, and relationships – Macro development Process • Refine CS 585 16
OO Modeling § James Rumbaugh Method – Object Modeling Technique (OMT) for • Analysis, creates: – The object model – objects, classes, and relationships – The dynamic model – objects and system behavior – The Functional Model – DFD like • System level design • Object level design CS 585 17
OO Modeling § Ivar Jacobson Method – Object Oriented Software Engineering – Use Cases Oriented method CS 585 18
The Unified Modeling Language CS 585 19
Why do we model? § Provide structure for problem solving § Experiment to explore multiple solutions § Furnish abstractions to manage complexity § Reduce time-to-market for business problem solutions § Decrease development costs § Manage the risk of mistakes CS 585 20
The Challenge Tijuana “shantytown”: http: //www. macalester. edu/~jschatz/residential. html CS 585 21
The Vision Fallingwater: http: //www. adelaide. net. au/~jpolias/FLW/Images/Falling. Water. jpeg CS 585 22
Why do we model graphically? § Graphics reveal data. § 1 bitmap = 1 megaword. – Anonymous visual modeler CS 585 23
What is UML § The UML is a graphical language for – Specifying, can be used to communicate "what" is required of a system, and "how" a system may be realized. – Visualizing, it can be used to visually depict a system before it is realized – Constructing, can be used to guide the realization of a system similar to a "blueprint". – Documenting, can be used for capturing knowledge about a system throughout its life-cycle the artifacts of software systems CS 585 24
What is UML § Added to the list of OMG adopted technologies in November 1997 as UML 1. 1 § Most recent minor revision is UML 2. 0, § MDA CS 585 25
OMG UML Contributors Aonix Colorado State University Computer Associates Concept Five Data Access EDS Enea Data Hewlett-Packard IBM I-Logix In. Line Software Intellicorp Kabira Technologies Klasse Objecten Lockheed Martin Microsoft Objec. Time Oracle Ptech OAO Technology Solutions Rational Software Reich SAP Softeam Sterling Software Sun Taskon Telelogic Unisys … CS 585 26
OMG UML Specification § § UML Summary UML Semantics UML Notation Guide UML Standard Profiles – Software Development Processes – Business Modeling § UML CORBAfacility Interface Definition § UML XML Metadata Interchange DTD § Object Constraint Language CS 585 27
the Language § language = syntax + semantics – syntax = how the symbols should look and how are they combined (i. e words in natural language) – semantics = rules that tells us the meanings of each symbol. § UML Notation Guide – defines UML’s graphic syntax § UML Semantics – defines UML’s semantics CS 585 28
UML Views § User model view – The system from the user’s perspective. • Use-cases UML Analysis Modeling § Structural model view – Static structure • Classes, objects, and relationships § Behavioral model view – Dynamic aspect of the system including collaborations between elements identified in the user-model and the structural model views. § Implementation model view UML Design Modeling – Describes the structural and behavioral aspects of the implementation. § Environment model view – Shows the actual hardware that is required to implement the solution. CS 585 29
UML Diagrams Inter object behavior Diagram UML decomposition dimension Use case diagram Functional Class diagram Static Collaboration diagram Dynamic Sequence diagram Dynamic Intra object behavior Statecharts Dynamic CS 585 30
UML Views Static View Class Diagram Object Diagram Dynamic View Functional View Sequence Diagram Collaboration Diagram State Chart Diagram Use Case Diagram Activity Diagram CS 585 31
Structural model view or Static View UML Views § Structural model view – Class Diagram § User model view § Behavioral model view § Implementation model view § Environment model view CS 585 32
Structural model view or Static View What is structural modeling? § Structural model: a view of a system that emphasizes the structure of the objects, including their classes, relationships, attributes and operations. § Used to model the static structure and relationships among the classes of an OO software system § A class diagram is made of: – Nodes (Classes and Interfaces) – Links (Relationships) CS 585 33
UML Class Diagram § Source for code generation § It represents classes, their members, and relationships. It includes: – Attributes – Operations – Stereotypes – Associations – Inheritance – Properties § It shows static view § Blueprint for building § Does not show behavior CS 585 34
UML Class Diagram - Modeling Attributes § An Attribute describes a piece of information – Show type of attribute • Primitive (Language supplied data type, int, boolean) • User defined class (String) – Show visibility • - private • + public • # protected • ~ package – Show default value – Show Constraints – Integrity rules – Show static values by underlining the attribute – Example Visibility / attribute Name: Data Type = default value {constraint} CS 585 35
UML Class Diagram - Modeling Operations § An operation denotes behavior – Things an object can do and – Things can be done to an object – Show Name – Show arguments – use attribute notation – Show return type – use attribute notation – Visibility (-, +, #, ~) – Example + total. Order. Amount (order: Order): Dollar {total >0} CS 585 36
Structural model view or Static View Class Representation in UML § class Point { int x, y; public void move (int dx, int dy) { x += dx; Point y += dy; } §} ~x: int ~y: int +move(dx: int, dy: int) CS 585 37
Structural model view or Static View Object Representation in UML § Point p 1 = new Point (); § p 1. x = 0; p 2. y=0; § p 1. move (20, 15); P 1: Point x =0 y=0 After sending the move message to p 1 object P 1: Point x =20 y=15 CS 585 38
Modeling Relationships With UML §Association 39 CS 585
Structural model view or Static View Relationships in UML § Association – To permit the exchange of messages • Associations are the mean for objects to communicate – Default is bi-directional (support messages in either way) – When an object uses the services of another object but does not own it. – Client server CS 585 40
Structural model view or Static View Class Diagram: Association § General Binary Relationship enroll Student Advisee Course * * * teach 1 Adviser 1 CS 585 Faculty 41
Association Elements - Association Name § Association Name – Expresses the purpose of the association (verb) that describes how objects of one type (class) relate to objects of another type (class) • A Person owns a Car • A Person drives a Car • A Person rents a Car – You can show the direction to read the association name Person owns Car rents Car drives Car CS 585 42
Association Elements - Multiplicity § Association Multiplicity – Defines rules on how objects in each class are related – A value can be assigned to each participant in the association – Min. . Max – * denotes zero or more – 1. . * no upper limit Person drives 0. . * 1. . 1 CS 585 Car 43
Association Elements - Roles § Association Roles – Generates code participate manager Employee participate Project programmer UI Designer participate CS 585 44
Association Elements - Constraints § Association Constraints Person drives Car Must have valid driver license CS 585 45
Association Elements - Class § Association Class – Encapsulate the association in a class to include information about the association Customer order 0. . * Product Order -order. Quantity: int = 0 -order. Date: Date = today -order. Terms: Terms=NULL CS 585 46
Association Elements - Reflexive § Reflexive Association – Objects in the same class can be associated and related to one another – Common for modeling Hierarchies 0. . * supervisor Employee 0. . * subordinates CS 585 47
Association Elements - Qualified § Qualified Association – Indexes – The customer uses the order number to lookup the order – Used to reduce multiplicity just like indexes are used to reduce time to search a table Customer order. No: int places 1. . 1 Order -order. Quantity: int = 0 -order. Date: Date = today -order. Terms: Terms=NULL CS 585 48
Associations Job 1. . * * Company employer employee Job salary worker * Person boss 0. . 1 Manages CS 585 49
Modeling Relationships With UML §Inheritance – Specialization and Generalization 50 CS 585
Structural model view or Static View Modeling Relationships With UML - Inheritance § Inheritance – – – Not a form of Association (no multiplicity) Extension Relationship (specialization and generalization) Extension between two interfaces Implementation (when a class implements an interface) UML uses hollow triangle (pointing toward the super class § Inheritance – – specialization and Generalization “is-a” One class is a specialization of another The child has all the characteristics of a parent and it might specialize them – Example: A mammal is-a-kind-of Animal A cat is-a-kind-of Animal CS 585 51
Structural model view or Static View Class Diagram: Inheritance Student “is-a” Relationship Undergrad Graduate Interface Master Implementation Ph. D Extension Relationship Implementation of an Interface CS 585 52
Structural model view or Static View Generalization “is-a” or “type-of” § Vehicle – Car Representation of inheritance – Motorcycle – Truck Car A car “is-a” Vehicle a Truck “is-a” Vehicle Motorcycle Truck Specialization occurs when sub-classes additional functionality or override existing ones CS 585 53
Structural model view or Static View Generalization - Inheritance § Credit Card Class is a subclass of the Bank Card Class § Credit Card Class is a specialization of the Bank Card Class Bank Card § Bank Card Class is a supper class of the Credit Card Class § Bank Card Class is a Generalization of the Credit Card Class § Credit Card Class is a Bank Card Class § Bank Card Class is base/ § Credit Card Class inherits from the Bank Card Class § Credit Card Class is derived from the parent class of the Credit Card Class Bank Card Class Credit Card Credit card is a special kind of card Debit Card Loan Card Specialization occurs when sub-classes additional functionality or override existing ones n. Inheritance is an implementation of the generalization relationship CS 585 54
Modeling Relationships With UML §Aggregation and Composition 55 CS 585
Structural model view or Static View Relationships in UML- Aggregation & Composition § Aggregation (diamond at the owner) – Is a type of Association used to indicate that objects are not independent , rather they (the parts) are assembled or configured together to create another object (the whole) • A number of different parts are assembled to create a Car object – One object contains another. – The aggregation class is referred to as the owner, or whole. The aggregated class is the owned, or part. – Example: a window has a drawing area, the drawing area can't stand on its own. CS 585 56
Structural model view or Static View Relationships in UML- Aggregation & Composition § Composition (filled in diamond at the owner) – Strong aggregation – the owner is responsible for creating and destroying of the part object. – Composite object that creates it’s components – Example: an active object with multiple threads of control. – Is used for aggregation where the life span of the part is dependent on the whole. The aggregate has control over the creation and destruction of the parts § Aggregation & Composition Modeling – Small diamond at the end of association denotes Aggregation – If diamond is filled it’s a Composition (“Consist of”) CS 585 57
Structural model view or Static View Aggregation & Composition Examples Team Chess Board Book 0. . 1 9. . 9 1 64 1 1. . * CS 585 Player Square Chapter 58
Structural model view or Static View Composition CS 585 59
Example § See Figure 2. 7 Page 35 for Class Diagram Aggregation and Composition Example CS 585 60
Modeling Relationships With UML §Dependency 61 CS 585
Structural model view or Static View Class Diagram: Dependency § One operation of a class 1 depends on another operation of class 2 – Use relationship – Class C 1 depends on class C 2 if C 1 uses C 2. § In many instances, a client-server relationship exists between two classes. – In such cases, a client-class depends on the server-class in some way and a dependency relationship is established CS 585 62
Structural model view or Static View Structural Modeling: Core Relationships CS 585 63
UML Views § User model view • Use-cases § Structural model view § Behavioral model view § Implementation model view § Environment model view CS 585 64
User. Modeling Requirements with UML Model view or Functional View §Use-Case Diagram 65 CS 585
User Model view or Functional View Modeling Requirements With USE-CASES § Used to model Requirements § Describes the behavior of the system as seen by external entities called actors § Each actor represent a role played by a set of external entities that interact with the system § Describes “what” § Each use case represent a scenario CS 585 66
Software Engineering: A Practitioner’s Approach, 6/e Use-case diagram Modeling Requirements with UML CS 585 67
Modeling Requirements With USE-CASES § Used to model Requirements § Describes the behavior of the system as seen by external entities – Actors – Other Systems § Each actor represent a role played by a set of external entities that interact with the system § Describes “what” § Each use case represent a scenario CS 585 68
Modeling Requirements With USE-CASES § Model the system from the end-user's perspective. § Objectives: – Define the functional and operational requirements of the system (product) by defining a scenario of usage. (These should be agreed upon by the users and developers. ) – Describes how the system and the users will interact. § use case model: a view of a system that emphasizes the behavior as it appears to outside users. § A use case model partitions system functionality into transactions (‘use cases’) that are meaningful to users (‘actors’). CS 585 69
Use Case Modeling § Use Case model has three views – The use case diagram • High level definition of the relationship between the system and its users (actors) • Block box view of the system – The use case narrative • Standard set of information that is required to guide for the development of the feature • Textual description – The use case scenarios • One logical sequence of the execution of the use case. CS 585 70
Use Case Modeling System Name Assumption Pre Conditions Dialog Post Conditions Exceptions Future Enhancements Open Issues Use Case diagram Defined by UML Use Case Narrative CS 585 Use Case Scenario 71
Modeling Requirements With USE-CASES § A use case diagram is made of: – System – Use cases defines required feature of the system – Actors – Association Relationships • between use-cases and actors • It represents the fact that Actors communicate with the use case – Dependencies Relationships – Defines a communication relationship between 2 use cases • • Include Extend – Generalization Relationships • Inheritance relationship between 2 actors or 2 use cases CS 585 72
User Model view or Functional View Use Case Modeling: Core Elements CS 585 73
Use Case Modeling: Core Relationships <<extend>> CS 585 74
User Model view or Functional View Use Case Modeling: Core Relationships (cont’d) <<include>> CS 585 75
User Model view or Functional View Use Case Diagram CS 585 76
User Model view or Functional View Use Case Diagram - Relationships § Association – Communication between actors and use cases – Uni or Bi directional § <<include>> – When one use case seeks help form another – Example Deposit Money use case includes the Update Account use case – Delegate – Dashed arrow form the using use case to the used use case Withdraw Cash <<include>> CS 585 Update Account 77
User Model view or Functional View Use Case Diagram - Relationships § <<extend>> – The extend Dependency says that one use case might need help from another use case – The extension point is the point where the extended use cases is tested to see weather its needed or not – Arrow is going from the use case that is providing help to the main use case <<include>> Withdraw Cash <<extend>> Withdraw Cash with Overdraft CS 585 Update Account Protect Overdraft 78
User Model view or Functional View Use Case Diagram - Relationships § Generalization – Inheritance relationship between use cases <<include>> Update Account Withdraw Cash Customer Withdraw Cash with Overdraft <<extend>> Protect Overdraft CS 585 79
User Model view or Functional View Use Case Relationships CS 585 80
User Model view or Functional View Actor Relationships CS 585 81
User Model view or Functional View Use Case Description: Change Flight n. Actors: traveler, client account db, airline reservation system n. Preconditions: · Traveler has logged on to the system and selected ‘change flight itinerary’ option n. Basic course · System retrieves traveler’s account and flight itinerary from client account database · System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment. · System asks traveler for new departure and destination information; traveler provides information. · If flights are available then · … · System displays transaction summary. n. Alternative courses · If no flights are available then … CS 585 82
User Model view or Functional View When to model use cases § Model user requirements with use cases. § Model test scenarios with use cases. § If you are using a use-case driven method – start with use cases and derive your structural and behavioral models from it. § If you are not using a use-case driven method – make sure that your use cases are consistent with your structural and behavioral models. CS 585 83
User Model view or Functional View Use Case Modeling Tips § Make sure that each use case describes a significant chunk of system usage OR FEATURE that is understandable by both domain experts and programmers § When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams § Factor out common usages that are required by multiple use cases – If the usage is required use <<include>> – If the base use case is complete and the usage may be optional, consider use <<extend>> § A use case diagram should – contain only use cases at the same level of abstraction – include only actors who are required CS 585 84
User Model view or Functional View Example: Online HR System CS 585 85
User Model view or Functional View Online HR System: Use Case Relationships CS 585 86
User Model view or Functional View Online HR System: Update Benefits Use Case n. Actors : employee, employee account db, healthcare plan system, insurance plan system n. Preconditions: · Employee has logged on to the system and selected ‘update benefits’ option n. Basic course · System retrieves employee account from employee account db · System asks employee to select medical plan type; include Update Medical Plan. · System asks employee to select dental plan type; include Update Dental Plan. · … n. Alternative courses · If health plan is not available in the employee’s area the employee is informed and asked to select another plan. . . CS 585 87
Modeling Behavior with UML §Sequence Diagram §State Diagram 88 CS 585
Sequence Diagram § Depicts Object Interaction in time § Used to capture Scenarios (Use cases) § Step-by-step sequence of messages exchanges among objects. § Map directly to use cases – Used to realize a use case § Example 2. 11 Page 37 CS 585 89
State Diagram § Each class must be associated with a statechart that describes its behavior. – Sequence diagrams show behavior of objects and how they collaborate to achieve the goal at hand (Inter. Object). – State Diagram show the behavior of an object (Intra. Object) § Depicts flow of control using states and transitions CS 585 90
on State Diagram Lamp On on off Lamp Off CS 585 91
State Diagram ON ON OFF CS 585 92
The States of a System § state—a set of observable circumstances that characterizes the behavior of a system at a given time § state transition—the movement from one state to another § event—an occurrence that causes the system to exhibit some predictable form of behavior § action—process that occurs as a consequence of making a transition [Event-List] [Guard] / [Action] §Example 2. 11 Page 37 CS 585 93
Object Behavior - Object Life Cycle Can be captured by Statecharts Initialize Object Wait for Request Handle Request Terminate Object stop CS 585 94
Statecharts § Statechart is a behavioral language for the specification behavioral of real-time, event driven, and reactive systems. – states – events FULL – actions – Transitions Put [no. OFitems=MAX] / print(”writing”) Event [Condition] / Action CS 585 PARTIA L 95
Basic UML Statechart Diagram “top” state Initial pseudostate State top Trigger Ready Transition stop /ctr : = 0 Final state Done stop CS 585 Action 96
Скачать презентацию Principals of Object Orientation OO Analysis
83abf2600e78a1a5454785ff9d64032c.ppt