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

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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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’

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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.

© Bennett, McRobb and Farmer 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

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

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

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

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

© Bennett, McRobb and Farmer 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

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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

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

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

© Bennett, McRobb and Farmer 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.

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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

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

© Bennett, McRobb and Farmer 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

© Bennett, McRobb and Farmer 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)

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

Feb-1643 Next Lecture: Detailed Design

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  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 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 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 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 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 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 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 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 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 Interfaces

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

Designing Associations

57 Designing Associations

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 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 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 Integrity Constraints Is a member of Employee chairs {subset of} 0..1 * * * Committee memberCollection[*] committeeChair assignChair() Constraints between Associations

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

CSE323 Systems Analysis and Design 2/ Feb-16