Www. CSE323 การวิเคราะห์และออกแบบระบบ (Systems...
-
Upload
belinda-bond -
Category
Documents
-
view
225 -
download
0
description
Transcript of Www. CSE323 การวิเคราะห์และออกแบบระบบ (Systems...
www.themegallery.com
CSE323CSE323 การวเิคราะห์และออกแบบระบบ การวเิคราะห์และออกแบบระบบ ((Systems Analysis and DesignSystems Analysis and Design))
Lecture 9:Lecture 9:System Design and Detail System Design and Detail DesignDesign
www.themegallery.com
© Bennett, McRobb and Farmer 2005 2
System DesignSystem 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 2005
3
In This Lecture You Will Learn: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 2005
4
How is Design Different from How is Design Different from Analysis?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 2005
5
How is Design DifferentHow is Design Differentfrom Analysis?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 2005
6
How is Design Different from How is Design Different from Analysis?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 2005
7
When Does Analysis StopWhen Does Analysis Stopand Design Start?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 2005
8
Traditional DesignTraditional 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 2005
9
Design in the Iterative Life Design in the Iterative Life CycleCycle
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 2005
10
SeamlessnessSeamlessness
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 2005
11
Logical and Physical DesignLogical 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 2005
12
Logical and PhysicalLogical and PhysicalDesign ExampleDesign 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 2005
13
Logical and Physical DesignLogical 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 2005
14
Model Driven ArchitectureModel 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 2005
15
System Design System Design and Detailed Designand 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 2005
16
System Design System Design and Detailed Designand 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 2005
17
Qualities of AnalysisQualities 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 2005
18
Qualities of DesignQualities 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 2005
19
Qualities of DesignQualities 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 2005
20
Qualities of DesignQualities 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 2005
21
Criteria for Good Design: Criteria for Good Design: CouplingCoupling
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 2005
22
Criteria for Good Design: Criteria for Good Design: CohesionCohesion
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 2005
23
Interaction CouplingInteraction 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 2005
24
Inheritance Inheritance CCouplingoupling
Vehicle
decription serviceDate maximumAltitude takeOffSpeed
checkAltitude() takeOff()
LandVehicle
numberOfAxles registrationDate register()
Inheritance Coupling describes the degree to which a subclass actually needs the features it inherits from its base class.
Poor inheritance Poor inheritance coupling as coupling as unwanted attributes unwanted attributes and operations are and operations are inheritedinherited
© Bennett, McRobb and Farmer 2005
25
Operation Cohesion Operation Cohesion
Lecturer
lecturerName lecturerAddress roomNumber roomLength roomWidth calculateRoomSpace()
{return roomLenght* roomWidth;}
Good operation cohesion but poor class cohesion
© Bennett, McRobb and Farmer 2005
26
Poor Specialization CohesionPoor Specialization Cohesion
Address
number street town county country postCode
Person
personName age gender
Company
companyName annualIncome annualProfit
Specialization Cohesion addresses the semantic cohesion of inheritance hierarchies
© Bennett, McRobb and Farmer 2005
27
Improved StructureImproved Structure
Address
number street town county country postCode
Person
personName age gender
Company
companyName annualIncome annualProfit
lives at is based at
Improved structure using Address class.
© Bennett, McRobb and Farmer 2005
28
Liskov Substitution PrincipleLiskov Substitution Principle
Disinheritance Disinheritance of of debit()debit() means that the means that the left-hand left-hand hierarchy is not hierarchy is not Liskov Liskov compliantcompliant
© Bennett, McRobb and Farmer 2005
29
Measurable Objectives in Measurable Objectives in DesignDesign
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 2005
30
Measurable Objectives in Measurable Objectives in DesignDesign
To reduce invoice errors by one-third within a year
How would you design for this?
© Bennett, McRobb and Farmer 2005
31
Measurable Objectives in Measurable Objectives in DesignDesign
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 2005
32
Measurable Objectives in Measurable Objectives in DesignDesign
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 2005
33
Planning for DesignPlanning 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 2005
34
Development StandardsDevelopment Standards
HCI guidelines Input/output device guidelines Construction guidelines
© Bennett, McRobb and Farmer 2005
35
I/O I/O DDevice evice HHierarchyierarchy
IODevice
handleEvent()
Sensor
handleEvent()
Actuator
handleEvent()
I/O Hierarchy providing consistency for device handling
© Bennett, McRobb and Farmer 2005
36
Prioritizing Design Trade-offsPrioritizing 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 2005
37
Trade-offs in DesignTrade-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 2005
38
Trade-offs in DesignTrade-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 2005
39
Design for ImplementationDesign for Implementation
Initialization and implementation issues should be considered.
There may be data transfer and/or data conversion requirements.
© Bennett, McRobb and Farmer 2005
40
SummarySummary
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 2005
41
ReferencesReferences
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 2005
42
ReferencesReferences
Rumbaugh et al (1991) Coad & Yourdon (1991) Yourdon (1994).
(For full bibliographic details, see Bennett, McRobb and Farmer)
05/05/23 43
Next Lecture:Next Lecture:
Detailed DesignDetailed Design
www.themegallery.com 44
Detailed DesignDetailed 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 InterfacesClass Specification and Interfaces Section 14.3 – 14.4 (pp. 397 – 403)
Designing AssociationsDesigning Associations Section 14.5 (pp. 404 – 409)
Integrity ConstraintsIntegrity Constraints Section 14.6 (pp. 409 – 412)
Design Hints for JavaDesign Hints for Java
OutlineOutline
46
Class Specification: Class Specification: AttributesAttributes
nnameame :: type-expression type-expression == initial-value initial-value {{property-property-stringstring}} 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: Class Specification: AttributesAttributes
BankAccount class with attribute types
included
Shows a derived attribute
BankAccount
nextAccountNumber: IntegeraccountNumber: IntegeraccountName: String {not null}balance: Money = 0/availableBalance: MoneyoverdraftLimit: Money
open(accountName: String):Booleanclose(): Booleancredit(amount: Money): Booleandebit(amount: Money): BooleanviewBalance(): MoneygetBalance(): MoneysetBalance(newBalance: Money)getAccountName(): StringsetAccountName(newName: String)
Arrays can be specified, e.g., qualification[0..10]:String
48
Class Specification: Class Specification: OperationsOperations
operation-name operation-name ((parameter-listparameter-list)) :: return-type- return-type-expressionexpression 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: Class Specification: OperationsOperations
BankAccount class with operation
signatures included.
BankAccount
nextAccountNumber: IntegeraccountNumber: IntegeraccountName: String {not null}balance: Money = 0/availableBalance: MoneyoverdraftLimit: Money
open(accountName: String):Booleanclose(): Booleancredit(amount: Money): Booleandebit(amount: Money): BooleanviewBalance(): MoneygetBalance(): MoneysetBalance(newBalance: Money)getAccountName(): StringsetAccountName(newName: String)
50
Visibility symbol
Visibility Meaning
+ Public The feature (an operation or an attribute) is directly accessible by an instance of any class.
- Private The feature may only be used by an instance the class that includes it.
# Protected The feature may be used either by the class that includes it or by a subclass or descendant of that class.
~ Package The feature is directly accessible only by instances of a class in the same package.
VisibilityVisibility
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)
VisibilityVisibility
52
InterfacesInterfaces
An interface in UML is a group of externally An interface in UML is a group of externally visible, i.e., public operations. 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
InterfacesInterfaces
UML supports two notations to show interfacesUML 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 The realizerealize relationship 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
- staffNo - staffName - staffStartDate - qualif ication
CreativeStaff
+ calculateBonus() + linkToNote()
- title - type - targetDate - estimatedCost - completionDate
Advert
+ getCost() + setCompleted() + view()
Realize relationships
«interface» Manageable
+ getCost() + setCompleted() + view()
«interface» Viewable
+ view()
Manageable Viewable
- companyName - companyAddress - companyTelephone - companyFax - companyEmail - contactName - contactTelephone - contactEmail
Client
+ assignStaffContact() + changeStaffContact()
«use» «use»
«realize» «realize»
InterfacesInterfaces
55
Designing AssociationsDesigning Associations
One-way vs. Two-way 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 AssociationsDesigning Associations
57
- staffNo - staffName - staffStartDate - qualification
CreativeStaff
+ calculateBonus() + linkToNote()
*
1
1..*
manage campaign
work on campaign
owns*
1
- title - campaignStartDate - campaignFinishDate - estimatedCost - completionDate - datePaid - actualCost
Campaign
+ assignManager() + assignStaff() + checkBudget() + checkStaff() + completed() + getDuration()
+ getTeamMembers() + linkToNote() + listAdverts() + recordPayment()
- title - type - targetDate - estimatedCost - completionDate
Advert
+ getCost() + setCompleted()
+ view()
*
One - way association
Two - way association
Designing AssociationsDesigning Associations
58
Designing AssociationsDesigning Associations
Collection ClassesCollection 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 AssociationsDesigning Associations
Designing AssociationsDesigning Associations
Designing AssociationsDesigning Associations
62
Integrity ConstraintsIntegrity Constraints
Referential IntegrityReferential Integrity an object identifier in an object must actually refer to an
object that exists Dependency ConstraintsDependency 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 IntegrityDomain Integrity attributes can only hold permissible values
63
Integrity ConstraintsIntegrity Constraints
Is a member of
Employee
chairs
{subset of}
0..1
*
*
*
Committee
memberCollection[*]
committeeChair
assignChair()
Constraints between Associations
64
Class Design Hints for JavaClass 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 JavaInheritance 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/2549
6605/05/23