1 / 41

ITEC 2010 Systems Analysis and Design, I LECTURE 9: Object-Oriented Design

2. Topics. Object-Oriented DesignObject-Oriented Architectural DesignComponent DiagramsDeployment DiagramsObject-oriented Design ProcessDesign ClassesFundamental Design Principles. 3. Object-Oriented DesignThe Bridge Between Analysis and Programming. Bridge between users' requirements and new

val
Download Presentation

ITEC 2010 Systems Analysis and Design, I LECTURE 9: Object-Oriented Design

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. 1

    2. 2 Topics Object-Oriented Design Object-Oriented Architectural Design Component Diagrams Deployment Diagrams Object-oriented Design Process Design Classes Fundamental Design Principles

    3. 3 Object-Oriented DesignThe Bridge Between Analysis and Programming Bridge between users requirements and new systems programming Object-oriented design is process by which detailed object-oriented models are built Programmers use design to write code and test new system User interface, network, controls, security, and database require design tasks and models

    4. 4 Overview of Object-Oriented Programs Set of objects that cooperate to accomplish result Object contains program logic and necessary attributes in a single unit Objects send each other messages and collaborate to support functions of main program OO systems designer provides detail for programmers Design class diagrams, interaction diagrams, and some state machine diagrams

    5. 5 Object-Oriented Event-Driven Program Flow

    6. 6 Object-Oriented Design: Processes and Models Diagrams developed for analysis/requirements Use case diagrams, use case descriptions and activity diagrams, domain model class diagrams, and system sequence diagrams Diagrams developed for design Component diagrams and Deployment diagrams Interaction diagrams and package diagrams Design class diagrams

    7. 7

    8. 8 Object-Oriented Architectural Design Desktop system Enterprise-level system Network or client/server system Internet based system

    9. 9 Differences between network and Internet systems

    10. 10 Component Diagrams and Architectural Design Component Diagram Shows overall system architecture API is the set of all public methods available in the component Ports and Sockets define the interface Frameset notation to extend UML notation Used to describe web components

    11. 11 Component Diagram Notation

    12. 12 Two-layer Architectural Design of an Internet System

    13. 13 Three-layer Architectural Design of an Internet system

    14. 14 Sample Web Services Design

    15. 15 Deployment Diagrams Deployment diagram shows physical components of a new system Node is a physical component Artifact is an executable module Artifacts are components after they have been compiled into executables

    16. 16 Sample Deployment Diagram of an Internet System

    17. 17 Fundamental Principles of Object-Oriented Detailed Design Design class diagrams and detailed sequence diagrams Use each other as inputs and are developed in parallel Sequence diagrams define the interactions between objects in order to execute a use case. Interactions are called messages Correspond to method calls in programming language Design Classes show attributes and method signatures

    18. 18 Sample Sequence Diagram

    19. 19 Sample Design Class

    20. 20

    21. 21 Object-oriented Design Process

    22. 22 Just for Fun!

    23. 23 Design Class Symbols UML does not distinguish between design class notation and domain model notation Domain model class diagram shows conceptual classes in users work environment Design class diagram specifically defines software classes UML uses stereotype notation to categorize a model element by its characteristics

    24. 24 Standard Stereotypes Found in Design Models

    25. 25 Standard Design Classes Entity design identifier for problem domain class Persistent class exists after system is shut down Control mediates between boundary and entity classes, between the view layer and domain layer Boundary designed to live on systems automation boundary, touched by users User interface and windows classes Data access retrieves data from and sends data to database

    26. 26 Design Class Notation Name class name and stereotype information Attribute visibility (private or public) attribute name, type-expression, initial-value, property Method signature information needed to invoke (or call) the method Method visibility, method name, type-expression (return parameter), method parameter list (incoming arguments)? Overloaded method method with same name but two or more different parameter lists Class-level method method associated with class instead of each object (static or shared method), denoted by an underline

    27. 27 Notation Used to Define a Design Class

    28. 28 Design Class Definitions Overloaded method a method with one name but different parameter lists Class-level method a method associated with the class rather than an object Class-level attribute an attribute that contains the same value for all objects Overridden method a method in a subclass that overrides the parents method Abstract class a class that is never instantiated Concrete class a normal class with objects

    29. 29 Sample Class Diagram with Design Classes and Inheritance

    30. 30 Developing the First-cut Design Class Diagram Elaborate the attributes Visibility, Type cast, Initial values Navigation Visibility Ability to reference the methods of another object

    31. 31 Navigation Visibility

    32. 32 Navigation Visibility Guidelines One-to-many with superior to subordinate. The visibility goes from the superior to the subordinate Mandatory relationships for existence. Visibility goes from independent to dependent Object needs information from another object. Visibility goes to object with the information Navigational arrows may be bidirectional

    33. 33 First Cut Class Diagram for RMO

    34. 34 Detailed Design with CRC cards Class-Responsibility-Collaboration Design process Select a single use case Identify class with primary responsibility Identify other classes that collaborate with primary class (become requests for service to other classes)? Identify responsibilities within each class (these become methods)?

    35. 35 CRC Card Notation

    36. 36 CRC Card Set for Process new order

    37. 37

    38. 38 Some Fundamental Design Principles Encapsulation each object is self-contained unit that includes data and methods that access data Object reuse designers often reuse same classes for windows components Information hiding data associated with object is not visible to outside world

    39. 39 Some Fundamental Design Principles (continued) Coupling qualitative measure of how closely classes in a design class diagram are linked Number of navigation arrows in design class diagram or messages in a sequence diagram Loosely coupled system is easier to understand and maintain Cohesion qualitative measure of consistency of functions within a single class Separation of responsibility divide low cohesive class into several highly cohesive classes Highly cohesive system is easier to understand and maintain and reuse is more likely

    40. 40 Some Fundamental Design Principles (continued)? Protection from variations parts of a system that are unlikely to change are segregated from those that will Indirection an intermediate class is placed between two classes to decouple them but still link them Object responsibility Objects are responsible for system processing Responsibilities include knowing and doing

    41. 41

More Related