1. www.themegallery.com CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture 9: System Design and Detail Design System Design and Detail Design

2. www.themegallery.com © Bennett, McRobb and Farmer 2005 2 System Design Based on Chapter 13 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (3rd Edition), McGraw Hill, 2005.

3. © Bennett, McRobb and Farmer 2005 3 In This Lecture You Will Learn:  The difference between analysis and design  The difference between logical and physical design  The difference between system and detailed design  The characteristics of a good design  The need to make trade-offs in design

4. © Bennett, McRobb and Farmer 2005 4 How is Design Different from Analysis?  Design states ‘how the system will be constructed without actually building it’ (Rumbaugh, 1997)  Analysis identifies ‘what’ the system must do  Design specifies ‘how’ it will do it

5. © Bennett, McRobb and Farmer 2005 5 How is Design Different from Analysis?  The analyst seeks to understand the organization, its requirements and its objectives  The designer seeks to specify a system that will fit the organization, provide its requirements effectively and assist it to meet its objectives

6. © Bennett, McRobb and Farmer 2005 6 How is Design Different from Analysis?  As an example, in the Agate case study:  analysis identifies the fact that the Campaign class has a title attribute  design determines how this will be entered into the system, displayed on screen and stored in a database, together with all the other attributes of Campaign and other classes

7. © Bennett, McRobb and Farmer 2005 7 When Does Analysis Stop and Design Start?  In a waterfall life cycle there is a clear transition between the two activities  In an iterative life cycle the analysis of a particular part of the system will precede its design, but analysis and design may be happening in parallel  It is important to distinguish the two activities and the associated mindset  We need to know ‘what’ before we decide ‘how’

8. © Bennett, McRobb and Farmer 2005 8 Traditional Design  Making a clear transition from analysis to design has advantages  project management—is there the right balance of activities?  staff skills—analysis and design may be carried out by different staff  client decisions—the client may want a specification of the ‘what’ before approving spending on design  choice of development environment—may be delayed until the analysis is complete

9. © Bennett, McRobb and Farmer 2005 9 Design in the Iterative Life Cycle  Advantages of the iterative life cycle include  risk mitigation—making it possible to identify risks earlier and to take action  change management—changes to requirements are expected and properly managed  team learning—all the team can be involved from the start of the project  improved quality—testing begins early and is not done as a ‘big bang’ with no time

10. © Bennett, McRobb and Farmer 2005 10 Seamlessness  The same model—the class model—is used through the life of the project  During design, additional detail is added to the analysis classes, and extra classes are added to provide the supporting functionality for the user interface and data management  Other diagrams are also elaborated in design activities

11. © Bennett, McRobb and Farmer 2005 11 Logical and Physical Design  In structured analysis and design a distinction has been made between logical and physical design  Logical design is independent of the implementation language and platform  Physical design is based on the actual implementation platform and the language that will be used

12. © Bennett, McRobb and Farmer 2005 12 Logical and Physical Design Example  Some design of the user interface classes can be done without knowing whether it is to be implemented in Java, C++ or some other language—types of fields, position in windows  Some design can only be done when the language has been decided upon—the actual classes for the types of fields, the layout managers available to handle window layout

13. © Bennett, McRobb and Farmer 2005 13 Logical and Physical Design  It is not necessary to separate these into two separate activities  It may be useful if the software is to be implemented on different platforms  Then it will be an advantage to have a platform- independent design that can be tailored to each platform

14. © Bennett, McRobb and Farmer 2005 14 Model Driven Architecture  Note the MDA  Generate platform-specific models (PSMs) from platform-independent models (PIMs) This is discussed in more detail in Chapter 12

15. © Bennett, McRobb and Farmer 2005 15 System Design and Detailed Design  System design deals with the high level architecture of the system  structure of sub-systems  distribution of sub-systems on processors  communication between sub-systems  standards for screens, reports, help etc.  job design for the people who will use the system

16. © Bennett, McRobb and Farmer 2005 16 System Design and Detailed Design  Object-oriented detailed design adds detail to the analysis model  types of attributes  operation signatures  assigning responsibilities as operations  additional classes to handle user interface  additional classes to handle data management  design of reusable components  assigning classes to packages

17. © Bennett, McRobb and Farmer 2005 17 Qualities of Analysis  Correct scope—everything in the system is required  Completeness—everything required is in the system and everything is documented in the models  Correct content—accurate description of requirements  Consistency—each element is consistently referred to by the same name

18. © Bennett, McRobb and Farmer 2005 18 Qualities of Design  Functional—system will perform the functions that it is required to  Efficient—the system performs those functions efficiently in terms of time and resources  Economical—running costs of system will not be unnecessarily high  Reliable—not prone to hardware or software failure, will deliver the functionality when the users want it

19. © Bennett, McRobb and Farmer 2005 19 Qualities of Design  Secure—protected against errors, attacks and loss of valuable data  Flexible—capable of being adapted to new uses, to run in different countries or to be moved to a different platform  General—general-purpose and portable (mainly applies to utility programs)  Buildable—Design is not too complex for the developers to be able to implement it

20. © Bennett, McRobb and Farmer 2005 20 Qualities of Design  Manageable—easy to estimate work involved and to check of progress  Maintainable—design makes it possible for the maintenance programmer to understand the designer’s intention  Usable—provides users with a satisfying experience (not a source of dissatisfaction)  Reusable—elements of the system can be reused in other systems

21. © Bennett, McRobb and Farmer 2005 21 Criteria for Good Design: Coupling  Coupling describes the degree of interconnectedness between design components  reflected by the number of links an object has and by the degree of interaction the object has with other objects

22. © Bennett, McRobb and Farmer 2005 22 Criteria for Good Design: Cohesion  Cohesion is a measure of the degree to which an element contributes to a single purpose  The concepts of coupling and cohesion are not mutually exclusive but actually support each other  Coad and Yourdon (1991) suggested several ways in which coupling and cohesion can be applied within an object-oriented approach

23. © Bennett, McRobb and Farmer 2005 23 Interaction Coupling  A measure of the number of message types an object sends to other objects and the number of parameters passed with these message types.  Should be kept to a minimum to reduce the possibility of changes rippling through the interfaces and to make reuse easier.

24. © Bennett, McRobb and Farmer 2005 24 Inheritance Coupling Inheritance Coupling describes the degree to which a subclass actually needs the features it inherits from its base class. Poor inheritance coupling as unwanted attributes and operations are inherited

25. © Bennett, McRobb and Farmer 2005 25 Operation Cohesion Good operation cohesion but poor class cohesion

26. © Bennett, McRobb and Farmer 2005 26 Poor Specialization Cohesion Specialization Cohesion addresses the semantic cohesion of inheritance hierarchies

27. © Bennett, McRobb and Farmer 2005 27 Improved Structure Improved structure using Address class.

28. © Bennett, McRobb and Farmer 2005 28 Liskov Substitution Principle Disinheritance of debit() means that the left-hand hierarchy is not Liskov compliant

29. © Bennett, McRobb and Farmer 2005 29 Measurable Objectives in Design  In Chapter 6, non-functional requirements were described  How can we tell whether these have been achieved?  Measurable objectives set clear targets for designers  Objectives should be quantified so that they can be tested

30. © Bennett, McRobb and Farmer 2005 30 Measurable Objectives in Design  To reduce invoice errors by one-third within a year  How would you design for this?

31. © Bennett, McRobb and Farmer 2005 31 Measurable Objectives in Design  To reduce invoice errors by one-third within a year  How would you design for this?  sense checks on quantities  comparing invoices with previous ones for the same customer  better feedback to the user about the items ordered

32. © Bennett, McRobb and Farmer 2005 32 Measurable Objectives in Design  To process 50% more orders at peak periods  How would you design for this?  design for as many fields as possible to be filled with defaults  design for rapid response from database  design system to handle larger number of simultaneous users

33. © Bennett, McRobb and Farmer 2005 33 Planning for Design  Planning for when platform is known  Setting standards  Allowing time for training  Agreeing objectives and planning tests  Agree procedures to decide on trade-offs that significantly affect the system  Planning time for different aspects of design

34. © Bennett, McRobb and Farmer 2005 34 Development Standards  HCI guidelines  Input/output device guidelines  Construction guidelines

35. © Bennett, McRobb and Farmer 2005 35 I/O Device Hierarchy I/O Hierarchy providing consistency for device handling

36. © Bennett, McRobb and Farmer 2005 36 Prioritizing Design Trade-offs  Designer is often faced with design objectives that are mutually incompatible.  It is helpful if guidelines are prepared for prioritizing design objectives.  If design choice is unclear users should be consulted.

37. © Bennett, McRobb and Farmer 2005 37 Trade-offs in Design  Design to meet all these qualities may produce conflicts  Trade-offs have to be applied to resolve these  Functionality, reliability and security are likely to conflict with economy  Level of reliability, for example, is constrained by the budget available for the development of the system

38. © Bennett, McRobb and Farmer 2005 38 Trade-offs in Design  Design objectives may conflict with constraints imposed by requirements  The requirement that the system can be used in different countries by speakers of different languages will mean that designers have to agree a list of all prompts, labels and messages and refer to these by some system of naming or numbering  This increases flexibility and maintainability but increases the cost of design

39. © Bennett, McRobb and Farmer 2005 39 Design for Implementation  Initialization and implementation issues should be considered.  There may be data transfer and/or data conversion requirements.

40. © Bennett, McRobb and Farmer 2005 40 Summary In this lecture you have learned about:  The difference between analysis and design  The difference between logical and physical design  The difference between system and detailed design  The characteristics of a good design  The need to make trade-offs in design

41. © Bennett, McRobb and Farmer 2005 41 References  More detail about design is provided in Chapters 12, 14 to 18  In particular, Chapter 14 covers Class Design (For full bibliographic details, see Bennett, McRobb and Farmer)

42. © Bennett, McRobb and Farmer 2005 42 References  Rumbaugh et al (1991)  Coad & Yourdon (1991)  Yourdon (1994). (For full bibliographic details, see Bennett, McRobb and Farmer)

43. Feb-1643 Next Lecture: Detailed Design

44. www.themegallery.com 44 Detailed Design Detailed Design Based on Chapter 13 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (3rd Edition), McGraw Hill, 2005.

45. 45  Class Specification and Interfaces  Section 14.3 – 14.4 (pp. 397 – 403)  Designing Associations  Section 14.5 (pp. 404 – 409)  Integrity Constraints  Section 14.6 (pp. 409 – 412)  Design Hints for Java Outline

46. 46 Class Specification: Attributes  name : type-expression = initial-value {property-string}  name is the attribute name  type-expression is its data type  initial-value is the value the attribute is set to when the object is first created  property-string describes a property of the attribute, such as constant or fixed

47. 47 Class Specification: Attributes BankAccount class with attribute types included Shows a derived attribute BankAccount nextAccountNumber: Integer accountNumber: Integer accountName: String {not null} balance: Money = 0 /availableBalance: Money overdraftLimit: Money open(accountName: String):Boolean close(): Boolean credit(amount: Money): Boolean debit(amount: Money): Boolean viewBalance(): Money getBalance(): Money setBalance(newBalance: Money) getAccountName(): String setAccountName(newName: String) Arrays can be specified, e.g., qualification[0..10]:String

48. 48 Class Specification: Operations  operation-name (parameter-list) : return-type-expression  An operation’s signature is determined by the operation’s name, the number and type of its parameters and the type of the return-value if any  Which operations Generally don’t show primary operations (constructor, destructor, get and set operations) Only show constructors where they have special significance Varying levels of detail at different stages in the development cycle

49. 49 Class Specification: Operations BankAccount class with operation signatures included. BankAccount nextAccountNumber: Integer accountNumber: Integer accountName: String {not null} balance: Money = 0 /availableBalance: Money overdraftLimit: Money open(accountName: String):Boolean close(): Boolean credit(amount: Money): Boolean debit(amount: Money): Boolean viewBalance(): Money getBalance(): Money setBalance(newBalance: Money) getAccountName(): String setAccountName(newName: String)

50. 50 Visibility symbol VisibilityMeaning + PublicThe feature (an operation or an attribute) is directly accessible by an instance of any class. - PrivateThe feature may only be used by an instance the class that includes it. # ProtectedThe feature may be used either by the class that includes it or by a subclass or descendant of that class. ~ PackageThe feature is directly accessible only by instances of a class in the same package. Visibility

51. 51 BankAccount class with visibility specified BankAccount - nextAccountNumber: Integer - accountNumber: Integer - accountName: String {not null} - balance: Money = 0 - /availableBalance: Money - overdraftLimit: Money + open(accountName: String):Boolean + close(): Boolean + credit(amount: Money): Boolean + debit(amount: Money): Boolean + viewBalance(): Money # getBalance(): Money - setBalance(newBalance: Money) # getAccountName(): String # setAccountName(newName: String) Visibility

52. 52 Interfaces  An interface in UML is a group of externally visible, i.e., public operations.  On occasions a class (or some other component) may present more than one external interface to other classes or the same interface may be required from more than one class.  The interface contains no internal structure, it has no attributes, no associations and the implementation of the operations is not defined.  Formally, an interface is equivalent to an abstract class that has no attributes, no associations and only abstract operations.

53. 53 Interfaces  UML supports two notations to show interfaces  The small circle icon showing no detail  A stereotyped class icon with a list of the operations supported  The realize relationship  indicates that the client class supports at least the operations listed in the interface  is represented by the dashed line with a triangular arrowhead

54. 54 Interfaces

55. 55 Designing Associations  One-way vs. Two-way Associations  An association that has to support message passing in both directions is a two-way association  A two-way association is indicated with arrowheads at both ends  Minimizing the number of two-way associations keeps the coupling between objects as low as possible

56. Designing Associations

57. 57 Designing Associations

58. 58 Designing Associations  Collection Classes  Collection classes are used to hold the object identifiers when message passing is required from one to many along an association  OO languages provide support for these requirements. Frequently the collection class may be implemented as part of the sending class (e.g. Campaign ) as some form of list

59. 59 has 1 * 1 - title: String - campaignStartDate: Date - campaignFinishDate: Date - estimatedCost: Money - completionDate: Date - datePaid: Date - actualCost: Money - ownedAdvertCollection: AdvertCollection Campaign + assignManager() + assignStaff() + checkBudget() + checkStaff() + completed() + getDuration() + getTeamMembers() + linkToNote() + listAdverts() + recordPayment() - title: String - type: String - targetDate: Date - estimatedCost: Money - completionDate: Date Advert + getCost() + setCompleted() + view() owns - ownedAdvert: Advert [*] AdvertCollection + findFirst() + getNext() + addAdvert() + removeAdvert() 1 One-way One-to-Many Association using a Collection Class Designing Associations

62. 62 Integrity Constraints  Referential Integrity  an object identifier in an object must actually refer to an object that exists  Dependency Constraints  attribute dependencies, where one attribute may be calculated from other attributes, must be maintained consistently  dependency constraints may also exist between or among associations  Domain Integrity  attributes can only hold permissible values

63. 63 Integrity Constraints Is a member of Employee chairs {subset of} 0..1 * * * Committee memberCollection[*] committeeChair assignChair() Constraints between Associations

64. 64 Class Design Hints for Java  Always keep data private  Always initialize data  Don't use too many basic types in a class  Not all fields need individual field accessors and mutators  Use a standard form for class definitions  Break up classes with too many responsibilities  Make the names of your classes and methods reflect their responsibilities --- Core Java

65. 65 Inheritance Design Hints for Java  Place common operations and fields in the superclass  Don't use protected fields  Use inheritance to model the "is–a" relationship  Don't use inheritance unless all inherited methods make sense  Don't change the expected behaviour when you override a method  Use polymorphism, not type information  Don't overuse reflection --- Core Java

66. CSE323 Systems Analysis and Design 2/2549 66 Feb-16