Lesson 5- Identify Design Elements

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

0
60
lượt xem
6
download

Lesson 5- Identify Design Elements

Mô tả tài liệu
  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ủ đề:
Lưu

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

  1. Object Oriented Analysis and Design Using the UML Module 5: Identify Design Elements Rational 1 Proprietary and Confidential
  2. 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
  3. Identify Design Mechanisms in Context I dentfiy  D esign  El ent em s Ar t chiect Rational 3 Proprietary and Confidential
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. Identify Design Elements Steps  Identify classes and subsystems  Identify subsystem interacts  Update the organization of the design model  Checkpoints Rational 9 Proprietary and Confidential
  10. 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
  11. From Analysis Classes to Design Elements Analysis Classes Design Elements Many-to-Many Mapping Rational 11 Proprietary and Confidential
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
Đồng bộ tài khoản