Systems Analysis and Design in a Changing World, Fifth Edition

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

2. 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. 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. 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. 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. Object-Oriented Three-Layer Program

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

8. Design Models with Their Respective Input Models

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

10. Differences between network and Internet systems

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

12. Component Diagram Notation

13. Two-layer Architectural Design of an Internet System

14. Three-layer Architectural Design of an Internet system

15. Sample Web Services Design

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

17. Sample Deployment Diagram of an Internet System

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

19. Sample Sequence Diagram

20. Sample Design Class

21. Sample Java Class Definition

22. Object-oriented Design Process

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. Standard Stereotypes Found in Design Models

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 system’s automation boundary, touched by users • User interface and windows classes • Data access – retrieves data from and sends data to database

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. Notation Used to Define a Design Class

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. Sample Class Diagram with Design Classes and Inheritance

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. Navigation Visibility

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. First Cut Class Diagram for RMO

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. CRC Card Notation

36. CRC Card Set for Process new order

37. Updated Design Class Diagram withVisibility and Methods

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

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