Lesson 5- Identify Design Elements

Chia sẻ: An Nguyen | Ngày: | Loại File: PPT | Số trang:66

Thêm vào BST

Báo xấu

122
lượt xem 10
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Object Oriented Analysis and Design Using the UML Module 5: Identify Design Elements Rational Proprietary and Confidential 1 .Objectives: Identify Design Elements  Understand the purpose of the Identify Design Elements and understand where in

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Lesson 5- Identify Design Elements

Object Oriented Analysis and Design Using the UML Module 5: Identify Design Elements Rational 1 Proprietary and Confidential
Objectives: Identify Design Elements  Understand the purpose of the Identify Design Elements and understand where in the lifecycle it is performed  To understand how to analyze interactions of analysis classes to identify design model elements  Design classes  Subsystems  Subsystems Interfaces Rational 2 Proprietary and Confidential
Identify Design Mechanisms in Context I dentfiy D esign El ent em s Ar t chiect Rational 3 Proprietary and Confidential
Identify Design Elements Overview  The Activity: Use Case Analysis results in analysis classes, which represent conceptual things which can perform behavior. In design, analysis classes evolve into a number of different kinds of design elements: Rational 4 Proprietary and Confidential
Identify Design Elements Overview Software Architecture Supplementary Design Document Specifications Guidelines Identify Design Analysis Classes Elements Design Model Design Model Rational 5 Proprietary and Confidential
Purpose  Purpose:  To anal i er i yze nt actons ofanal s asses o i ysi cl t fnd i eraces,cl nt f asses and subsyst s. em  To efne he chiect e,i r i t ar t ur ncor atng euse por i r w her possi e. e bl  To dentf com m on utons o i iy sol i t com m onl y encount ed er desi pr em s. gn obl  To ncl i ude chiect aly gnii ar t ur l si fcantpars he t oft desi m odeli t Logi ew gn n he calVi Rational 6 Proprietary and Confidential
Input and Output  I nputA r iact : tf s  Suppl ent y em ar Specii i fcatons  Glossary  Sofw ar Ar t ur D ocum ent t e chiect e  D esi M odel gn  Anal s l ysi C asses  D esi G ui i gn delnes  R esuli A r iact : tng tf s  D esi M odel( l gn C asses and Subsyst s) em  U pdat Sofw ar Ar t ur D ocum ent ed t e chiect e  U pdat D esi G ui i ed gn delnes Rational 7 Proprietary and Confidential
Class, Subsystem, interface overview  Classes, to represent a set of rather fine-grained responsibilities;  Subsystems, to represent a set of coarse- grained responsibilities, eventually composed of a further set of classes and possibly subsystems;  Interfaces, to represent abstract declarations of responsibilities provided by a class or subsystem; Rational 8 Proprietary and Confidential
Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interacts  Update the organization of the design model  Checkpoints Rational 9 Proprietary and Confidential
Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interfaces  Identify reuse opportunities  Update the organization of the design model  Checkpoints Rational 10 Proprietary and Confidential
From Analysis Classes to Design Elements Analysis Classes Design Elements Many-to-Many Mapping Rational 11 Proprietary and Confidential
From Analysis Classes to Design Elements (cont.)  Anal s asses ysi cl handl prm arl f e i iy unctonal i requiem ent r s,and odelobj s r he m ect fom t " obl "dom ai gn em ent handl non pr em n;desi el s e functonalr i equiem ent r s,and odelobj s r m ect fom t " uton"dom ai he sol i n.  W e de hatanal s cl deci w ysi ‘ asses’ar r l e ealy classes,w hi ar subsyst s w hi m ustbe ch e em ( ch f t urherdecom posed) ,and hi ar exi i w ch e stng com ponent and s don’ tneed o “ t be desi gned”at al. l Rational 12 Proprietary and Confidential
From Analysis Classes to Design Elements (cont.)  O nce he gn asses t desi cl and subsyst s em have been eat cr ed,each ustbe ven nam e m gi a and a shor tdescrpton.The esponsi ltes he i i r biii oft orgi i nalanal s asses ysi cl shoul be r d tansf r t er ed o t new l cr ed he y eat subsyst sem Rational 13 Proprietary and Confidential
Identify Design Classes  An analysis class maps directly to a design class if:  It is a simple class  It represents a single logical abstraction  More complex analysis classes may  Split into multiple classes  Become a package  Become a subsystem (discussed later)  Any combination… Rational 14 Proprietary and Confidential
Review: Class and Package  What is a class?  A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics. Class Name  What is a package?  A general purpose mechanism for organizing elements into groups  A model element which can contain other model elements Package Name Rational 15 Proprietary and Confidential
Group Design Classes In Packages  When identifying classes, they should be grouped into Artifact: Design Packages  You can base your packaging criteria on a number of different factors  Configuration  Allocation of resources among development teams  Reflect the user types  Represent the existing products and services the system uses Rational 16 Proprietary and Confidential
Packaging Tips: Boundary Classes If it is likely the system interface will If it is unlikely the system interface will undergo considerable changes undergo considerable changes Boundary classes placed in Boundary classes packaged separate packages With functionally related classes Rational 17 Proprietary and Confidential
Packaging Tips: Functionally Related Classes  Criteria for determining if classes are functionally related  Changes in one class’ behavior and/or structure necessitate changes in anther class  Removal of one class impacts the other class  Two objects interact with a large number of messages or have a complex intercommunication  A boundary class can be functionally related to a particular entity class if the function of the boundary class is to present the entity class  Two classes interact with, or are affected by changes in the same actor Rational 18 Proprietary and Confidential
Packaging Tips: Functionally Related Classes(cont.)  Criteria for determining if classes are functionally related (continued)  Two classes have relationships between each other  One class creates instances of another class  Criteria for determining when two classes should NOT be placed in the same package  Two classes that are related to different actors should not be placed in the same package Rational 19 Proprietary and Confidential
Package Dependencies: Package Element Visibility PackageA Class A1 Class A2 A Class A3 Only public classes can be referenced PackageB outside of the B owning package +Class B1 -Class B2 Public visibility Private visibility OO Principle: Encapsulation Rational 20 Proprietary and Confidential