1 CS 501 Spring 2008 CS 501: Software Engineering Lectures 15 Object Oriented Design 1.

Slides:



Advertisements
Similar presentations
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
Advertisements

UML: An Introduction.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
CS CS 5150 Software Engineering Lecture 15 Object Oriented Design 1.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 18 Object Oriented Design II.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 15 Object Oriented Design 1.
CS 501: Software Engineering Fall 2000 Lecture 11 Object-Oriented Design I.
CS CS 5150 Software Engineering Lecture 15 Object Oriented Design 1.
Software Engineering Lecture 9 Object-Oriented Design II.
C++ Training Datascope Lawrence D’Antonio Lecture 11 UML.
© Copyright Eliyahu Brutman Programming Techniques Course.
Object-Orientated Design Unit 3: Objects and Classes Jin Sa.
Common Mechanisms in UML
CS 501: Software Engineering Fall 2000 Lecture 12 Object-Oriented Design II.
1 CS 501 Spring 2005 CS 501: Software Engineering Lecture 16 Object Oriented Design 2.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 16 Object Oriented Design I.
Software Engineering Case Study Slide 1 Introductory case study.
UML Sequence Diagrams Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
CS 5150 Software Engineering Lecture 15 Program Design 2.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
An Introduction to Software Architecture
Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and.
CS 360 Lecture 6.  A model is a simplification of reality  We build models to better understand the system being developed.  We build models of complex.
Presented by: CHAN LAI SAN ( ) REBAH DAW SARREB ( ) FIDA AL-OBAISI ( ) 08 April 2008 (Tuesday 6pm – 7:30pm)
Object Management Group (OMG) Specifies open standards for every aspect of distributed computing Multiplatform Model Driven Architecture (MDA)
1 UML Basic Training. UML Basic training2 Agenda  Definitions: requirements, design  Basics of Unified Modeling Language 1.4  SysML.
Systems Analysis and Design in a Changing World, 3rd Edition
CS CS 5150 Software Engineering Lecture 15 Program Design 1.
Unified Modeling Language* Keng Siau University of Nebraska-Lincoln *Adapted from “Software Architecture and the UML” by Grady Booch.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
Software Engineering Lecture 10 UML vs. ERD.
UHD::3320::CH121 DESIGN PHASE Chapter 12. UHD::3320::CH122 Design Phase Two Aspects –Actions which operate on data –Data on which actions operate Two.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
An Introduction to the Unified Modeling Language
UML as a Specification Language for Embedded Systems. By, Mir Ahmed Ali, Asst. Professor, ECM department, SNIST. By, Prof. Narsiah sir, Director of School.
Logical view –show classes and objects Process view –models the executables Implementation view –Files, configuration and versions Deployment view –Physical.
Part VII: Design Continuous
Design Model Lecture p6 T120B pavasario sem.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
Software Engineering Lecture 8 Object-Oriented Analysis.
 Building Block Building Block  Things in the UML Things in the UML  Structural Things Structural Things  Behavioral Things Behavioral Things  Grouping.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
Chapter 3: Introducing the UML
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 17 Object Oriented Design I.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 17 Object Oriented Design II.
Introduction to UML Hazleen Aris Software Eng. Dept., College of IT, UNITEN. …Unified Modeling Language.
Object Oriented Programming and Data Abstraction Earl Huff Rowan University.
CS 501: Software Engineering Fall 1999 Lecture 15 Object-Oriented Design I.
CHAPTER
Unified Modeling Language (UML)
UML Diagrams: Class Diagrams The Static Analysis Model
UML Diagrams By Daniel Damaris Novarianto S..
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Unified Modeling Language
Introduction to Unified Modeling Language (UML)
UML Diagrams Jung Woo.
CS 501: Software Engineering Fall 1999
CS 501: Software Engineering
Analysis models and design models
An Introduction to Software Architecture
Design Yaodong Bi.
Software Development Process Using UML Recap
CS 501: Software Engineering
Presentation transcript:

1 CS 501 Spring 2008 CS 501: Software Engineering Lectures 15 Object Oriented Design 1

2 CS 501 Spring 2008 Administration

3 CS 501 Spring 2008 Design in the modified Waterfall Model Requirements System design Testing Operation & maintenance Program design Implementation (coding) Acceptance & release Feasibility study Requirements Design Implementation

4 CS 501 Spring 2008 Program Design The task of program design is to represent the software system functions in a form that can be transformed into one or more executable programs. Given a system architecture, the program design specifies: programs, components, packages, classes and class hierarchies interfaces, protocols security mechanisms, operational procedures UML models (diagrams and specifications) can be used for almost all aspects of program design

5 CS 501 Spring 2008 Models: Levels of Abstraction The complexity of a model depends on its level of abstraction: High-levels of abstraction show the overall system. Low-levels of abstraction are needed for implementation. Two approaches: Model entire system at same level of abstraction, but present diagrams with different levels of detail. Model parts of system at different levels of abstraction.

6 CS 501 Spring 2008 UML Models A UML model consists of: (a)A diagram. This gives a general overview of the model, showing the principal elements and how they relate to each other. A diagram is the graphical representation of a set of elements, usually rendered as a connected graph of vertices (things) and arcs (relationships). (b)A specification. This provides details about each element of the model. Specification for models used in program design should have sufficient detail that they can be used to write code from.

7 CS 501 Spring 2008 List of all Diagrams in UML Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Principally used for requirements. Component diagram shows the organization and dependencies among a set of components. Principally used for system architecture. Deployment diagram shows the configuration of processing nodes and the components that live on them. Principally used for system architecture.

8 CS 501 Spring 2008 List of all Diagrams in UML These models are used principally for program design. Class diagram shows a set of classes, interfaces, and collaborations with their relationships. Object diagram shows a set of objects and their relationships.

9 CS 501 Spring 2008 These models are for interactive aspects of systems. They can be used for requirements or program design. 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 Statechart diagram shows a state machine consisting of states, transitions, events, and activities. Activity diagram is a statechart diagram that shows the flow from activity to activity within a system. List of all Diagrams in UML

10 CS 501 Spring 2008 Using Rational Rose for Program Design

11 CS 501 Spring 2008 Class Diagrams Window origin size open() close() move() display() name attributes (local, instance, and class variables) operations (methods) responsibilities (optional text) A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

12 CS 501 Spring 2008 The "Hello, World!" Example import java.awt.Graphics; class HelloWorld extends java.applet.Applet { public void paint (Graphics g) { g.drawString ("Hello, World!", 10, 10); } Example from: BJR

13 CS 501 Spring 2008 The HelloWorld Example HelloWorld paint() class name operations

14 CS 501 Spring 2008 Abstraction for HelloWorld HelloWorld paint() g.drawString ("HelloWorld", 0, 10)" class name operations annotation

15 CS 501 Spring 2008 Annotation some text note A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.

16 CS 501 Spring 2008 A Typical Class Diagram

17 CS 501 Spring 2008 Another Typical Design

18 CS 501 Spring 2008 Specification

19 CS 501 Spring 2008 Specification Fields

20 CS 501 Spring 2008 General Specification Fields

21 CS 501 Spring 2008 Notation: Grouping A package is a general-purpose mechanism for organizing elements into groups. Business rules

22 CS 501 Spring 2008 Packaging Classes applet awt lang HelloWorld java Graphics package

23 CS 501 Spring 2008 Notation: Relationships A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other * employer employee An association is a structural relationship that describes a set of links, a link being a connection among objects.

24 CS 501 Spring 2008 Relationships Parking ParkingSpace location is_available()

25 CS 501 Spring 2008 Notation: Relationships (continued) A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent). childparent A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

26 CS 501 Spring 2008 Generalization Applet HelloWorld paint() Graphics generalization dependency Note that the Applet and Graphics classes are shown elided, i.e., just the name is shown, not the attributes or operations.

27 CS 501 Spring 2008 Notation: Interface An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element. ISpelling

28 CS 501 Spring 2008 Class Inheritance Diagram Object Component Container Panel Applet HelloWorld ImageObserver interface

29 CS 501 Spring 2008 Modeling Classes Given a real-life system, how do you decide what classes to use? What terms do the users and implementers use to describe the system? They are candidates for classes. Is each candidate class crisply defined? For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes? What attributes and operations does each class need to carry out its responsibilities?

30 CS 501 Spring 2008 Coupling and Cohesion Coupling is a measure of the dependencies between two subsystems. If two systems are strongly coupled, it is hard to modify one without modifying the other. Cohesion is a measure of dependencies within a subsystem. If a subsystem contains many closely related functions its cohesion is high. Aim for high cohesion within classes and weak coupling between them.

31 CS 501 Spring 2008 Candidate Classes: Application Classes and Solution Classes Application classes and solution classes: Application classes represent application concepts. Noun identification is an effective technique to generate candidate application classes. Solution classes represent system concepts, e.g., user interface objects, databases, etc.

32 CS 501 Spring 2008 Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

33 CS 501 Spring 2008 Noun Identification: A Library Example The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules.

34 CS 501 Spring 2008 Candidate Classes Librarythe name of the system Book Journal Copy ShortTermLoanevent LibraryMember Weekmeasure MemberOfLibraryrepeat Itembook or journal Timeabstract term MemberOfStaff Systemgeneral term Rulegeneral term

35 CS 501 Spring 2008 Relations between Classes Bookis anItem Journalis anItem Copyis a copy of a Book LibraryMember Item MemberOfStaffis aLibraryMember Is Item needed?

36 CS 501 Spring 2008 Operations LibraryMemberborrowsCopy LibraryMemberreturnsCopy MemberOfStaffborrowsJournal MemberOfStaffreturnsJournal Item not needed yet.

37 CS 501 Spring 2008 Class Diagram MemberOfStaffBookCopyJournal is a copy of 1..* 1 LibraryMember 1 0..* on loan

38 CS 501 Spring 2008 Rough Sketch: Wholesale System A wholesale merchant supplies retail stores from stocks of goods in a warehouse. What classes would you use to model this business?

39 CS 501 Spring 2008 Rough Sketch: Wholesale System RetailStore Warehouse Order Invoice Product Shipment Merchant

40 CS 501 Spring 2008 Rough Sketch: Wholesale System Warehouse Order Invoice Product Merchant RetailStore name address contactInfo financialInfo Shipment Responsibilities -track status of shipped products Reversal damaged() return() wrongItem() responsibility (text field)

41 CS 501 Spring 2008 Expanding a Class: Modeling Financial Information RetailStore Transaction 1 * association Invoice Payment Which class is responsible for the financial records for a store?

42 CS 501 Spring 2008 Modeling Invoice Shipment Invoice invoiceNumber +goodsShipped() -sendInvoice() goodsShipped PartsList adornments + public - private RetailStore ??? invoiceRecord

43 CS 501 Spring 2008 Lessons Learned Design is empirical. There is no single correct design. During the design process: Eliding: Elements are hidden to simplify the diagram Incomplete: Elements may be missing. Inconsistency: The model may not be consistent The diagram is not the whole design. Diagrams must be backed up with specifications.

44 CS 501 Spring 2008 From Candidate Classes to Completed Design Methods used to move to final design: Reuse: Wherever possible use existing components, or class libraries. They may need modification. Restructuring: Change the design to improve, understandability, maintainability, etc. Techniques include merging similar classes, splitting complex classes, etc. Optimization: Ensure that the system meets anticipated performance requirements, e.g., by changed algorithms or restructuring. Completion: Fill all gaps, specify interfaces, etc.

45 CS 501 Spring 2008 An Exam Question: Object Oriented Design A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

46 CS 501 Spring 2008 Exam Question: Noun Identification A system generates weather maps using data collected from unattended weather stations. Each weather station collects meteorological data and produces summaries of the data. On request, it sends the summary information to an area computer. The area computer uses a database of digitized maps to generate a set of local weather maps.

47 CS 501 Spring 2008 Exam Question: Candidate Classes Systemgeneral term WeatherMap Datasame as MeteorologicalData WeatherStationis this a general term? MeteorologicalDatahow does this relate to WeatherStation? DataSummaryhow does this relate to MeteorologicalData? AreaComputerhardware Databasegeneral term DigitizedMap

48 CS 501 Spring 2008 Exam Question: Observations about the Candidate Classes WeatherMapis a DigitizedMap is derived from 1...* DataSummary WeatherStationhas a set of MeteorologicalData MeteorologicalData DataSummaryis derived from MeteorologicalData DigitizedMap Can Meteorological Data be an attribute of WeatherStation? Can DataSummary be combined with WeatherMap?

49 CS 501 Spring 2008 Exam Question: Attributes and Operations WeatherStation location metereologicalData collectData() getSummary() WeatherMap location date-time geographicData weather gatherData() printMap() DigitizedMap location geographicData printMap() Or should MetereologicalData be a separate object?

50 CS 501 Spring 2008 Exam Question: Class Diagram DigitizedMap 1...* 1 WeatherStation location metereologicalData collectData() getSummary() WeatherMap location date-time geographicData weather gatherData() printMap() summary *