1. Computing and SE II Chapter 9: Design Methods and Design Models Er-Yu Ding Software Institute, NJU

2. Main Contents 1.Design Methods 2.Structured Design 3.OO Design

3. 1. Design Methods Ad-hoc Structured OO

4. 1. Design Methods ——Ad-hoc Small Scale Designs – Come up with a block diagram – Place chips on board – Wire parts and components – Hope or Pray it works Large Scale Designs – Partition Design – Develop Library – Configure Design – Test Partial Design – Develop More Libraries – Configure More Designs –... – Complete Design

5. 1. Design Methods —— Structured Design Fundamentals of a Discipline of Computer Program and Systems Design Purpose – Make methodical the process of designing software systems Mainly business systems Approach – Defines properties of a good procedural(module) design – Defines a step-by-step method for transforming a data flow graph into a procedural(module) design

6. 1. Design Methods ——Object-Oriented Design Designing systems using self-contained objects and object classes Direct mapping of concepts in the problem domain to software units and their interfaces – Viewing the world as objects is more natural since it is closer to the way humans think Objects are more stable than functions… Supports information hiding, data abstraction, and encapsulation

7. 2. Structured Design Based on structured analysis Methods – Top-Down – Bottom-Up – Mixed Principles – Functional Decomposition (Divide and conquer) – Modularity and Information hiding Low coupling High internal cohesion

8. 2. Structured Design Top-Down – Refine Specification successively – Decompose each component into small Components – Lowest-level primitive components – Over-sold methodology - only works with plenty of experience – Suitable for small new design system In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.

9. 2. Structured Design Bottom-Up – Build-up from primitive components – Combined to form more complex components – Risk wrong interpretation of specifications – Mostly used for legacy system reengineering or enterprise application integration

10. 2. Structural Design Mixed – Mostly top-down, but also bits of bottom-up – Reality: need to know both top level and bottom level constraints – Suitable for large systems design

11. 2. Structured Design —— Review: Sturctured Analysis Model Data dictionary ERD DFD STD Control Specification (CSPEC) Data Object description Process specification (PSPEC) Data Behavior Function

12. 2. Structured Design —— Structured Design Models Data dictionary ERD Structured Chart STD Data Object description Flow Chart Decision Table PDL Data Behavior Function For Design Flow Chart Decision Table PDL

13. 2. Structured Design —— Transform Analysis Customer 4.1 Read Payment 4.2 Edit Payment 4.3 Process Payment 4.4 Update Balance 4.5 Update Open To Buy cheque, bill stub edited payment Accounts 4.6 Insert Payment Payments payment account, amount account, amount account, amount account, amount Afferent Flow Efferent Flow Central Transform Modularity and Information hiding!!!!

14. 2. Structured Design —— Structure Charts Input (Afferent Flow) Process Central Transform) Output (Efferent Flow) Input Process Output Control

15. 2. Structured Design —— Structure Charts - Notation Modules Library modules Module call Data Flag

16. 2. Structured Design —— Structure Charts - Example Process Payment Control Get Payment Process Payment Write Payment Read Record Edit Record Update Account Insert Payment Event Raw Payment Raw Payment Error Payment Error Payment Process Today Payment

17. 2. Structured Design —— Flow Chart

18. 2. Structured Design —— Decision Table

19. 2. Structured Design —— Program Design Language (PDL)

20. Requirements Collection and Analysis Data Requirements CONCEPTUAL DESIGN Conceptual Schema (in a high-level data model) LOGICAL DESIGN (DATA MODEL MAPPING) Logical (Conceptual) Schema (In the data model of a specific DBMS) PHYSICAL DESIGN Internal Schema Functional Requirements FUNCTIONAL ANALYSIS High-level Transaction Specification APPLICATION PROGRAM DESIGN TRANSACTION IMPLEMENTATION Application Program For Analysis For Design 2. Structured Design ——Phases of data design

21. Conceptual ERD Logical ERD

22. 2. Structured Design ——Phases of data design Physical ERD

23. 2. Structured Design ——STD for Analysis

24. 2. Structured Design ——STD for Design

25. 3. OO Design Object-oriented analysis, design and programming are related but distinct – OOA is concerned with developing an object model of the application domain – OOD is concerned with developing an object-oriented system model to implement requirements – OOP is concerned with realising an OOD using an OO programming language such as Java or C++

26. 3. OO Design ——Object Oriented Programming Concepts: – Programs are organized into cooperating collections of objects – Object: entity that encapsulates state and behavior. An instance of a class – Interface or protocol: set of messages to which it will respond – Response can be a message or routine, or delegation of the message to another object

27. 3. OO Design —— OOP Models

28. 3. OO Design —— Object-Oriented Analysis Examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain Yields black-box objects that are derived from the problem domain Scenarios can be used to determine necessary object behavior

29. 3. OO Design —— OO Analysis Model - UML Data Behavior Function Object State-chart diagram Interaction diagram Class diagram Object diagram Use case diagram Activity diagram

30. 3. OO Design —— Object-Oriented Design Object focus shifts to the solution domain – Objects, their semantics, and relationships are identified – Implementation and iteration occur – Quality and principles are focused Jacobsen says “when details of the implementation begin to show, it’s OOD” In my practice: OOA is preliminary design, and OOD is detailed design

31. 3. OO Design ——OOD Models Object State-chart diagram Interaction diagram Class diagram Activity diagram Data Behavior Function Package diagram Component diagram Compone nt Deployment diagram Deployment For Design

32. 3. OO Design ——Class Diagram for Design

33. 3. OO Design ——Activity Diagram for Diagram Analysis Design

34. 3. OO Design ——Sequence Diagram for Analysis Analysis

35. 3. OO Design ——Sequence Diagram for Design

36. 3. OO Design —— Component Model Defines the large-scale pieces of the system. Each of these pieces will contain smaller objects and will organize and orchestrate their behaviour Logical – Package Diagram Physical – Component Diagram

37. 3. OO Design ——Package Diagram

39. 3. OO Design —— Component Diagram Captures the physical structure of the Implementation Built as part of architectural specification Purpose – Organize source code – Construct an executable release – Specify a physical database

40. 3. OO Design —— Component Diagram

41. 3. OO Design —— Deployment Diagram Captures the topology of a system’s hardware Built as part of architectural specification Purpose – Specify the distribution of components – Identify performance bottlenecks Developed by architects, networking engineers, and system engineers Configuration of: – Run-time processing elements – Software components, processes, and objects that live on them. – What about Remote Components?

42. 3. OO Design —— Deployment Diagram

44. The End Next Lecture – HCI Design