1 / 22

CS 501: Software Engineering Fall 2000

CS 501: Software Engineering Fall 2000. Lecture 13 Object-Oriented Design III. Administration. Midterm examination • Monday, October 16, 7:30 to 8:30 pm, Phillips 219 • Closed book • About 5 questions on the material covered in lectures. Comments on Presentations. Presentation

aric
Download Presentation

CS 501: Software Engineering Fall 2000

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 501: Software EngineeringFall 2000 Lecture 13 Object-Oriented Design III

  2. Administration Midterm examination • Monday, October 16, 7:30 to 8:30 pm, Phillips 219 • Closed book • About 5 questions on the material covered in lectures

  3. Comments on Presentations Presentation • Standard of graphics has been high • Some text too small (diagrams, screen dumps) Content • Level of detail • Requirements v. design The client defines the requirements Well done, but time is short. What is your critical path?

  4. Modeling Dynamic Aspects of Systems Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them • Sequence diagrams: time ordering of messages • Collaboration diagrams: structural organization of objects that send and receive messages Activity diagram: flow chart showing flow of control from activity to activity Statechart diagram: models a state machine

  5. Bouncing Ball Diagrams Example: http://www.cs.cornell.edu/ domain name TCP connection HTTP get Client Servers

  6. Actions on Objects returnCopy(c) call return send create destroy okToBorrow() local status notifyReturn(b) asynchronous signal <<create>> stereotypes <<destroy>>

  7. Copy Links LibraryMember +borrowCopy() +returnCopy() 1 on loan 0..* association class message borrowCopy(c) c:Copy libMem:LibraryMember link object

  8. Sequence Diagram: Change in Cornell Program :MEngStudent Cornellian 1 : getName() 1.1 : name 2: new PhDStudent(name) :PhDStudent 3: <<destroy>> sequence numbers added to messages

  9. Sequence Diagram: Borrow copy of a Book libMem: LibraryMember theBook:Book BookBorrower theCopy:Copy borrow(theCopy) okToBorrow borrow borrow

  10. Class Inheritance Diagram Object Panel interface Component ImageObserver Applet Container HelloWorld

  11. Sequence Diagram:Painting Mechanism :Thread :Toolkit :ComponentPeer target:HelloWorld run run callbackLoop handleExpose paint

  12. Release work order Reschedule Assign tasks Activity Diagram: Process Modeling branch [materials not ready] [materials ready] guard expression

  13. Decompress Stream audio Stream video Activity Diagram: Parallel Activities start state fork join stop state

  14. State Diagram returned() returned() not borrowable borrowable borrowed()[last copy] guard expression borrowed()[not last copy] State diagram for class Book

  15. Implementation Modeling Subsystem A grouping of elements that specifies what a part of a system should do. Component (UML definition) "A distributable piece of implementation of a system, including software code (source, binary, or executable) but also including business documents, etc., in a human system." A component can be thought of as an implementation of a subsystem.

  16. Component Diagram executable component hello.java hello.hml HelloWorld.class hello.jpg

  17. Components and Classes agent.dll AgentAction PatternSearch Policy

  18. Components and Classes agent.dll Realizes AgentAction PatternSearch Policy extended component

  19. Components and Classes Classes represent logical abstractions. Components represent physical things. Components may live on nodes. Classes have attributes and operations directly. Components have operations that are reachable only through interfaces.

  20. Interfaces render.java simulation.exe IRender dependency realization interface

  21. Application Programming Interface (API) API is an interface that is realized by one or more components. simulation.exe IRender IModels ILighting

  22. Components and Replaceability Components allow system to be assembled from binary replaceable elements. • A component is physical -- bits not concepts • A component can be replaced by any other component(s) that conforms to the interfaces. • A component is part of a system. • A component provides the realization of a set of interfaces.

More Related