1. 11 Systems Analysis and Design in a Changing World, Fifth Edition

2. 11 Systems Analysis and Design in a Changing World, 5th Edition2 Learning Objectives  Explain the purpose and objectives of object-oriented design  Develop component diagrams and deployment diagrams  Develop design class diagrams  Use CRC cards to define class responsibilities and collaborations  Explain the fundamental principles of object-oriented design

3. 11 Systems Analysis and Design in a Changing World, 5th Edition3 Overview  This chapter is thorough explanation of how to design simple systems  Architechtural design is used to define the structure and configuration of the new system  Good object-oriented design is based on fundamental design principles  Design classes are a fundamental element in systems design  Class-Responsibility-Collaboration (CRC) cards are useful for designing simple systems

4. 11 Systems Analysis and Design in a Changing World, 5th Edition4 Object-Oriented Design—The Bridge Between Analysis and Programming  Bridge between users’ requirements and new system’s 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

5. 11 Systems Analysis and Design in a Changing World, 5th Edition5 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

6. 11 Systems Analysis and Design in a Changing World, 5th Edition6 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. 11 Systems Analysis and Design in a Changing World, 5th Edition7 Design Models with Their Respective Input Models Figure 11-2

8. 11 Systems Analysis and Design in a Changing World, 5th Edition8 Object-Oriented Architectural Design  Desktop system  Enterprise-level system Network or client/server system Internet based system

9. 11 Systems Analysis and Design in a Changing World, 5th Edition9 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

10. 11 Systems Analysis and Design in a Changing World, 5th Edition10 Sample Sequence Diagram Figure 11-12

11. 11 Systems Analysis and Design in a Changing World, 5th Edition11 Sample Design Class Figure 11-13

12. 11 Systems Analysis and Design in a Changing World, 5th Edition12 Sample Java Class Definition Figure 11-14(a)

13. 11 Systems Analysis and Design in a Changing World, 5th Edition13 Object-oriented Design Process Figure 11-15

14. 11 Systems Analysis and Design in a Changing World, 5th Edition14 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

15. 11 Systems Analysis and Design in a Changing World, 5th Edition15 Standard Stereotypes Found in Design Models Figure 11-16

16. 11 Systems Analysis and Design in a Changing World, 5th Edition16 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 system’s automation boundary, touched by users User interface and windows classes  Data access – retrieves data from and sends data to database

17. 11 Systems Analysis and Design in a Changing World, 5th Edition17 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

18. 11 Systems Analysis and Design in a Changing World, 5th Edition18 Notation Used to Define a Design Class Figure 11-17

19. 11 Systems Analysis and Design in a Changing World, 5th Edition19 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

20. 11 Systems Analysis and Design in a Changing World, 5th Edition20 Sample Class Diagram with Design Classes and Inheritance Figure 11-18

21. 11 Systems Analysis and Design in a Changing World, 5th Edition21 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

22. 11 Systems Analysis and Design in a Changing World, 5th Edition22 Navigation Visibility Figure 11-20

23. 11 Systems Analysis and Design in a Changing World, 5th Edition23 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

24. 11 Systems Analysis and Design in a Changing World, 5th Edition24 First Cut Class Diagram for RMO Figure 11-21

25. 11 Systems Analysis and Design in a Changing World, 5th Edition25 Updated Design Class Diagram with Visibility and Methods Figure 11-24

26. 11 Systems Analysis and Design in a Changing World, 5th Edition26 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

27. 11 Systems Analysis and Design in a Changing World, 5th Edition27 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

28. 11 Systems Analysis and Design in a Changing World, 5th Edition28 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

29. 11 Systems Analysis and Design in a Changing World, 5th Edition29 Summary  Object-oriented design is the bridge between user requirements (in analysis models) and final system (constructed in programming language)‏  Systems design is driven by use cases, design class diagrams, and CRC Cards Domain class diagrams are transformed into design class diagram

30. 11 Systems Analysis and Design in a Changing World, 5th Edition30 Summary (continued)‏  Object-oriented design principles must be applied Encapsulation – data fields are placed in classes along with methods to process that data Low coupling – connectivity between classes High cohesion – nature of an individual class 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 Separation navigation – access classes have to other classes  Three-layer design is used because maintainable