Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

5 transition to design


Published on

Published in: Technology
  • Login to see the comments

5 transition to design

  1. 1. Transition to Design
  2. 2. How is Design Different from Analysis? <ul><li>Design states &quot;how the system will be constructed without actually building it&quot; (Rumbaugh, 1997) </li></ul><ul><li>Ví dụ, trong Library case study: </li></ul><ul><ul><li>Phân tích xác định rằng lớp Book có thuộc tính title </li></ul></ul><ul><ul><li>Thiết kế xác định thuộc tính title được lưu trữ vào hệ thống như thế nào, hiển thị trên màn hình và lưu trữ trong cơ sở dữ liệu như thế nào. </li></ul></ul>Phân tích Thiết kế Xác định hệ thống phải làm “cái gì” (what) Chỉ ra hệ thống phải thực hiện điều đó như thế nào (how) Tìm hiểu tổ chức, xác định yêu cầu và mục tiêu của tổ chức. Xác định một hệ thống phù hợp với tổ chức, đáp ứng các yêu cầu của tổ chức một cách hiệu quả, và hỗ trợ tổ chức đạt được mục tiêu của nó.
  3. 3. Identify Design Elements
  4. 4. Objectives: Identify Design Elements <ul><li>Define the purpose of Identify Design Elements and demonstrate where in the lifecycle it is performed </li></ul><ul><li>Analyze interactions of analysis classes and identify Design Model elements </li></ul><ul><ul><li>Design classes </li></ul></ul><ul><ul><li>Subsystems </li></ul></ul><ul><ul><li>Subsystem interfaces </li></ul></ul>
  5. 5. Identify Design Elements in Context [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Refine the Architecture Design Components Design the Database (Optional) Identify Design Elements Architect
  6. 6. Identify Design Elements Overview Identify Design Elements Supplementary Specifications Software Architecture Document Design Model Analysis Model Project Specific Guidelines
  7. 7. Identify Design Elements Steps <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>
  8. 8. Identify Design Elements Steps <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>Analysis Classes
  9. 9. From Analysis Classes to Design Elements Analysis Classes Design Elements Many-to-Many Mapping Subsystem <<subsystem>> Subsystem <<subsystem>> <<boundary>> <<control>> <<entity>> <<boundary>>
  10. 10. Identifying Design Classes <ul><li>An analysis class maps directly to a design class if: </li></ul><ul><ul><li>It is a simple class </li></ul></ul><ul><ul><li>It represents a single logical abstraction </li></ul></ul><ul><li>More complex analysis classes may </li></ul><ul><ul><li>Split into multiple classes </li></ul></ul><ul><ul><li>Become a package </li></ul></ul><ul><ul><li>Become a subsystem (discussed later) </li></ul></ul><ul><ul><li>Any combination … </li></ul></ul>
  11. 11. <ul><li>What is a class? </li></ul><ul><ul><li>A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics </li></ul></ul><ul><li>What is a package? </li></ul><ul><ul><li>A general purpose mechanism for organizing elements into groups </li></ul></ul><ul><ul><li>A model element which can contain other model elements </li></ul></ul>Review: Class and Package Package Name Class Name
  12. 12. <ul><li>You can base your packaging criteria on a number of different factors, including: </li></ul><ul><ul><li>Configuration units </li></ul></ul><ul><ul><li>Allocation of resources among development teams </li></ul></ul><ul><ul><li>Reflect the user types </li></ul></ul><ul><ul><li>Represent the existing products </li></ul></ul><ul><ul><li>and services the system uses </li></ul></ul>Group Design Classes in Packages Package C Package B Package A
  13. 13. Packaging Tips: Boundary Classes If it is likely the system interface will undergo considerable changes Boundary classes placed in separate packages If it is unlikely the system interface will undergo considerable changes Boundary classes packaged with functionally related classes
  14. 14. Packaging Tips: Functionally Related Classes <ul><li>Criteria for determining if classes are functionally related: </li></ul><ul><ul><li>Changes in one class' behavior and/or structure necessitate changes in another class </li></ul></ul><ul><ul><li>Removal of one class impacts the other class </li></ul></ul><ul><ul><li>Two objects interact with a large number of messages or have a complex intercommunication </li></ul></ul><ul><ul><li>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 </li></ul></ul><ul><ul><li>Two classes interact with, or are affected by changes in the same actor </li></ul></ul>
  15. 15. Packaging Tips: Functionally Related Classes <ul><li>Criteria for determining if classes are functionally related (continued): </li></ul><ul><ul><li>Two classes have relationships between each other </li></ul></ul><ul><ul><li>One class creates instances of another class </li></ul></ul><ul><li>Criteria for determining when two classes should NOT be placed in the same package: </li></ul><ul><ul><li>Two classes that are related to different actors should not be placed in the same package </li></ul></ul><ul><ul><li>An optional and a mandatory class should not be placed in the same package </li></ul></ul>
  16. 16. Package Dependencies: Package Element Visibility PackageB PackageA Public visibility Private visibility Only public classes can be referenced outside of the owning package OO Principle: Encapsulation A B + Class A1 + Class A2 + Class A3 + Class B1 - Class B2
  17. 17. Package Coupling: Tips <ul><li>Packages should not be cross-coupled </li></ul><ul><li>Packages in lower layers should not be dependent upon packages in upper layers </li></ul><ul><li>In general, dependencies should not skip layers </li></ul>A B X A B Upper Layer Lower Layer C X X = Coupling violation X
  18. 18. Example: Registration Package MainRegistrarForm 1 1 1 MainStudentForm 1 RegisterForCoursesForm <<boundary>> 0..1 1 CloseRegistrationForm <<boundary>> 0..1 CloseRegistrationController <<control>> RegistrationController <<control>> 1
  19. 19. Example: University Artifacts Package Course - credits - name - curriculum - description - number 0..n 1 preRequisites 0..n 1 Professor - name - ProfessorId : UniqueId CourseOffering - number : String = &quot;100&quot; - startTime : Time - endTime : Time - days : Enum /- numStudents : Int 0..n 1 0..n 1 0..1 0..n instructor 0..1 0..n Schedule - semester 0..n 0..2 0..n alternateCourses 0..2 0..n 0..4 0..n primaryCourses 0..4 Student - studentID - name - address 0..n 1 0..n 1 ParttimeStudent - maxNumCourses FulltimeStudent - gradDate PrimaryScheduleOfferingInfob - grade ScheduleOfferingInfo - status
  20. 20. Example: External System Interfaces Package ICourseCatalogSystem + getCourseOfferings(forSemester : Semester) : CourseOfferingList + initialize() <<Interface>> IBillingSystem + submitBill(forTuition : Double, forStudent : Student) <<Interface>>
  21. 21. Identifying Subsystems <ul><li>A sub-system typically groups together elements of the system that share some common properties </li></ul><ul><li>An OO sub-system encapsulates a coherent set of responsibilities in order to ensure that it has integrity and can be maintained </li></ul><ul><li>Each subsystem has a well-defined interface with the rest of the system but does not describe its internal structure. </li></ul><ul><li>A sub-system can be designed and constructed independently of orther sub-systems. </li></ul>
  22. 22. <ul><li>Subsystems are a “cross between” a package (can contain other model elements) and a class (has behavior) </li></ul><ul><li>Realizes one or more interfaces that define its behavior </li></ul>Subsystems and Interfaces Subsystem Interface Realization (Canonical form) Realization (Elided form) Subsystem Name <<subsystem>> Interface Name <<interface>> Interface Name Subsystem Name <<subsystem>>
  23. 23. Subsystems and Interfaces (continued) <ul><li>Subsystems : </li></ul><ul><ul><li>Completely encapsulate behavior </li></ul></ul><ul><ul><li>Represent an independent capability with clear interfaces (potential for reuse) </li></ul></ul><ul><ul><li>Model multiple implementation variants </li></ul></ul>InterfaceK X() W() <<Interface>> SubsystemA <<subsystem>> SubsystemB <<subsystem>> ClassA1 W() ClassA2 X() ClassB1 W() Y() ClassB2 X() ClassB3 Z()
  24. 24. Packages versus Subsystems <ul><li>Subsystems </li></ul><ul><ul><li>Provide behavior </li></ul></ul><ul><ul><li>Completely encapsulate their contents </li></ul></ul><ul><ul><li>Are easily replaced </li></ul></ul><ul><li>Packages </li></ul><ul><ul><li>Don’t provide behavior </li></ul></ul><ul><ul><li>Don’t completely encapsulate their contents </li></ul></ul><ul><ul><li>May not be easily replaced </li></ul></ul>Encapsulation is the key! Subsystem A <<subsystem>> Package B ClassB1 ClassB2 Client Class
  25. 25. Subsystem Usage <ul><li>Subsystems can be used to partition the system into parts that can be independently: </li></ul><ul><ul><li>ordered, configured, or delivered </li></ul></ul><ul><ul><li>developed, as long as the interfaces remain unchanged </li></ul></ul><ul><ul><li>deployed across a set of distributed computational nodes </li></ul></ul><ul><ul><li>changed without breaking other parts of the systems </li></ul></ul><ul><li>Subsystems can also be used to: </li></ul><ul><ul><li>partition the system into units which can provide restricted security over key resources </li></ul></ul><ul><ul><li>represent existing products or external systems in the design (e.g. components) </li></ul></ul>Subsystems raise the level of abstraction.
  26. 26. Identifying Subsystems Hints <ul><li>Look at object collaborations. </li></ul><ul><li>Look for optionality. </li></ul><ul><li>Look to the user interface of the system. </li></ul><ul><li>Look to the actors. </li></ul><ul><li>Look for coupling and cohesion between classes. </li></ul><ul><li>Look at substitution. </li></ul><ul><li>Look at distribution. </li></ul><ul><li>Look at volatility. </li></ul>
  27. 27. Candidate Subsystems <ul><li>Analysis classes which may evolve into subsystems: </li></ul><ul><ul><li>Classes providing complex services and/or utilities (Security authorization services) </li></ul></ul><ul><ul><li>Boundary classes (user interfaces and external system interfaces) </li></ul></ul><ul><li>Existing products or external systems in the design (e.g., components): </li></ul><ul><ul><li>Communication software (middle-ware, COM/CORBA support) </li></ul></ul><ul><ul><li>Database access support (RDBMS mapping support) </li></ul></ul><ul><ul><li>Types and data structures (stacks, lists, queues) </li></ul></ul><ul><ul><li>Common utilities (math libraries) </li></ul></ul><ul><ul><li>Application-specific products (billing system, scheduler) </li></ul></ul>Subsystem A <<subsystem>> Subsystem B <<subsystem>>
  28. 28. Identifying Subsystems <<control>> ClassA X() W() X() W() <<Interface>> “ Superman Class” InterfaceK SubsystemA <<subsystem>> ClassA1 X() ClassA2 W()
  29. 29. Identify Design Elements Steps <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>
  30. 30. Identifying Interfaces <ul><li>Purpose </li></ul><ul><ul><li>To identify the interfaces of the subsystems based on their responsibilities </li></ul></ul><ul><li>Steps </li></ul><ul><ul><li>Identify a set of candidate interfaces for all subsystems. </li></ul></ul><ul><ul><li>Look for similarities between interfaces. </li></ul></ul><ul><ul><li>Define interface dependencies. </li></ul></ul><ul><ul><li>Map the interfaces to subsystems. </li></ul></ul><ul><ul><li>Define the behavior specified by the interfaces. </li></ul></ul><ul><ul><li>Package the interfaces. </li></ul></ul>Stable, well-defined interfaces are key to a stable, resilient architecture.
  31. 31. Interface Guidelines <ul><li>Interface name </li></ul><ul><ul><li>Reflects role in system </li></ul></ul><ul><li>Interface description </li></ul><ul><ul><li>Conveys responsibilities </li></ul></ul><ul><li>Operation definition </li></ul><ul><ul><li>Name should reflect operation result </li></ul></ul><ul><ul><li>Describes what operation does, all parameters and result </li></ul></ul><ul><li>Interface documentation </li></ul><ul><ul><li>Package supporting info: sequence and state diagrams, test plans, etc. </li></ul></ul>
  32. 32. Example: Design Subsystems and Interfaces All other analysis classes map directly to design classes. Analysis Design BillingSystem //submit bill() <<boundary>> Billing System <<subsystem>> IBillingSystem submitBill(forTuition : Double, forStudent : Student) CourseCatalogSystem //get course offerings() <<boundary>> Course Catalog System <<subsystem>> ICourseCatalogSystem getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList initialize()
  33. 33. Example: Analysis-Class-To-Design-Element Map Analysis Class Design Element CourseCatalogSystem CourseCatalogSystem Subsystem BillingSystem BillingSystem Subsystem All other analysis classes map directly to design classes
  34. 34. Modeling Convention: Subsystems and Interfaces Interfaces start with an “I” CourseCatalogSystem <<subsystem>> + initialize () + getCourseOfferings () ICourseCatalogSystem <<interface>> + getCourseOfferings () + initialize () CourseCatalogSystem <<subsystem>> ICourseCatalogSystem + initialize () + getCourseOfferings ()
  35. 35. Example: Subsystem Context: CourseCatalogSystem Provided interface defined ICourseCatalogSystem <<Interface>> CloseRegistrationController + // is registration open?() + // close registration() <<control>> 0..1 +courseCatalog CourseCatalogSystem <<subsystem>> + initialize () + getCourseOfferings () + getCourseOfferings (forSemester: Semester) + initialize () RegistrationController + getCurrentSchedule() + deleteCurrentSchedule() + submitSchedule() + saveSchedule() + getCourseOfferings() + setSession() + <<class>> new() + getStudent() <<control>> CourseOfferingList + new() + add() 1 Required interface defined
  36. 36. Example: Subsystem Context: Billing System IBillingSystem + submitBill(forStudent : Student, forTuition : double) <<Interface>> 1 0..1 + Biller Student <<entity>> CloseRegistrationController + // is registration open?() + // close registration() <<control>> BillingSystem <<subsystem>> + submitBill(forStudent : Student, forTuition : double)
  37. 37. Identify Design Elements Steps <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>
  38. 38. Identification of Reuse Opportunities <ul><li>Purpose </li></ul><ul><ul><li>To identify where existing subsystems and/or components can be reused based on their interfaces. </li></ul></ul><ul><li>Steps </li></ul><ul><ul><li>Look for similar interfaces </li></ul></ul><ul><ul><li>Modify new interfaces to improve the fit </li></ul></ul><ul><ul><li>Replace candidate interfaces with existing interfaces </li></ul></ul><ul><ul><li>Map the candidate subsystem to existing components </li></ul></ul>
  39. 39. Possible Reuse Opportunities <ul><li>Internal to the system being developed </li></ul><ul><ul><li>Recognized commonality across packages and subsystems </li></ul></ul><ul><li>External to the system being developed </li></ul><ul><ul><li>Commercially available components </li></ul></ul><ul><ul><li>Components from a previously developed application </li></ul></ul><ul><ul><li>Reverse engineered components </li></ul></ul>Software Software
  40. 40. Reuse Opportunities Internal to System ?
  41. 41. <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>Identify Design Elements Steps ClassB Y() Z() ClassA Y() Z() ClassC Y() Z() ClassD Y() Z() ClassC Y() Z() ClassE Y() Z()
  42. 42. Software Architecture <ul><li>A software architecture is a description of the sub-systems and components of a software system and the relationships between them. </li></ul><ul><li>The architecture of the information system is first considered early in the project during the requirements capture and analysis activities. </li></ul><ul><li>We will consider some of the major architecture styles </li></ul><ul><ul><li>Client/Server Architecture </li></ul></ul><ul><ul><li>Peer-to-Peer Architecture </li></ul></ul><ul><ul><li>Layered Architecture </li></ul></ul><ul><ul><li>Model/View/Controller </li></ul></ul>
  43. 43. Styles of sub-system communication The server sub-system does not depend on the client sub-system and is not affected by changes to the client’s interface. « client » Sub-system A « server » Sub-system B « peer » Sub-system D « peer » Sub-system C Each peer sub-system depends on the other and each is affected by changes in the other’s interface.
  44. 44. Layering and Partitioning <ul><li>Two general approaches to the division of a software system into sub-systems </li></ul><ul><ul><li>Layering – so called because the different sub-systems usually represent different levels of abstraction </li></ul></ul><ul><ul><li>Partitioning – which usually means that each sub-system focuses on a different aspect of the functionality of the system as a whole </li></ul></ul><ul><li>Both approaches are often used together on one system </li></ul>
  45. 45. Schematic of a Layered Architecture Closed architecture–messages may only be sent to the adjacent lower layer Open architecture–messages can be sent to any lower layer Layer 1 Layer 2 Layer N-1 Layer N Layer 1 Layer 2 Layer N-1 Layer N
  46. 46. Typical Layering Approach General functionality Specific functionality Distinct application subsystems that make up an application — contains the value adding software developed by the organization. Business specific — contains a number of reusable subsystems specific to the type of business. Middleware — offers subsystems for utility classes and platform-independent services for distributed object computing in heterogeneous environments and so on. System software — contains the software for the actual infrastructure such as operating systems, interfaces to specific hardware, device drivers, and so on. Application Business-Specific Middleware System Software
  47. 47. Three & Four Layer Architectures. Business logic layer can be split into two layers Database Access Business Logic Presentation Database Access Domain Application logic Presentation
  48. 48. Layering Considerations <ul><li>Visibility </li></ul><ul><ul><li>Dependencies only within current layer and below </li></ul></ul><ul><li>Volatility (Tính có thể thay đổi) </li></ul><ul><ul><li>Upper layers affected by requirements changes </li></ul></ul><ul><ul><li>Lower layers affected by environment changes </li></ul></ul><ul><li>Generality </li></ul><ul><ul><li>More abstract model elements in lower layers </li></ul></ul><ul><li>Number of layers </li></ul><ul><ul><li>Small system: 3-4 layers </li></ul></ul><ul><ul><li>Complex system: 5-7 layers </li></ul></ul>Goal is to reduce coupling and to ease maintenance effort.
  49. 49. Design Elements and the Architecture Layer 1 Layer 2 Layer 3
  50. 50. Example: Architectural Layers Middleware <<layer>> Base Reuse global Application <<layer>> Business Services <<layer>> Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI.
  51. 51. Partitioning Considerations <ul><li>Coupling and cohesion </li></ul><ul><li>User organization </li></ul><ul><li>Competency and/or skill areas </li></ul><ul><li>System distribution </li></ul><ul><li>Secrecy </li></ul><ul><li>Variability </li></ul>Try to avoid cyclic dependencies.
  52. 52. Example: Partitioning B A Package A Package B
  53. 53. Example: Application Layer Registration <<layer>> Application
  54. 54. Example: Application Layer Context Application <<layer>> Business Services <<layer>> <<layer>> Application <<layer>> Business Services Registration Security GUI Framework Secure Interfaces University Artifacts External System Interfaces
  55. 55. Example: Business Services Layer CourseCatalogSystem <<subsystem>> External System Interfaces University Artifacts ObjectStore Support <<layer>> Business Services GUI Framework Secure Interfaces Security <<subsystem>> Security Manager BillingSystem <<subsystem>>
  56. 56. Example: Business Services Layer Context Middleware <<layer>> Business Services <<layer>> java.sql com.odi <<layer>> Middleware BillingSystem <<subsystem>> CourseCatalogSystem <<subsystem>> External System Interfaces University Artifacts ObjectStore Support <<layer>> Business Services GUI Framework Secure Interfaces Security <<subsystem>> Security Manager
  57. 57. Example: Middleware Layer com.odi Database (from com.odi) Session (from com.odi) Transaction (from com.odi) Map (from com.odi) java.sql ResultSet (from com.odi) Connection (from com.odi) Statement (from com.odi) DriverManager (from com.odi) <<layer>> Middleware
  58. 58. Identify Design Elements Steps <ul><li>Identify classes and subsystems </li></ul><ul><li>Identify subsystem interfaces </li></ul><ul><li>Identify reuse opportunities </li></ul><ul><li>Update the organization of the Design Model </li></ul><ul><li>Checkpoints </li></ul>
  59. 59. Checkpoints <ul><li>General </li></ul><ul><ul><li>Does it provide a comprehensive picture of the services of different packages? </li></ul></ul><ul><ul><li>Can you find similar structural solutions that can be used more widely in the problem domain? </li></ul></ul><ul><li>Layers </li></ul><ul><ul><li>Are there more than seven layers? </li></ul></ul><ul><li>Subsystems </li></ul><ul><ul><li>Is subsystem partitioning done in a logically consistent way across the entire model? </li></ul></ul>
  60. 60. Checkpoints (continued) <ul><li>Packages </li></ul><ul><ul><li>Are the names of the packages descriptive? </li></ul></ul><ul><ul><li>Does the package description match with the responsibilities of contained classes? </li></ul></ul><ul><ul><li>Do the package dependencies correspond to the relationships between the contained classes? </li></ul></ul><ul><ul><li>Do the classes contained in a package belong there according to the criteria for the package division? </li></ul></ul><ul><ul><li>Are there classes or collaborations of classes within a package that can be separated into an independent package? </li></ul></ul><ul><ul><li>Is the ratio between the number of packages and the number of classes appropriate? </li></ul></ul>
  61. 61. Checkpoints (continued) <ul><li>Classes </li></ul><ul><ul><li>Does the name of each class clearly reflect the role it plays? </li></ul></ul><ul><ul><li>Is the class cohesive (i.e., are all parts functionally coupled)? </li></ul></ul><ul><ul><li>Are all class elements needed by the use-case realizations? </li></ul></ul><ul><ul><li>Do the role names of the aggregations and associations accurately describe the relationship? </li></ul></ul><ul><ul><li>Are the multiplicities of the relationships correct? </li></ul></ul>
  62. 62. Review: Identify Design Elements <ul><li>What is the purpose of Identify Design Elements? </li></ul><ul><li>What is an interface? </li></ul><ul><li>What is a subsystem? How does it differ from a package? </li></ul><ul><li>What is a subsystem used for, and how do you identify them? </li></ul><ul><li>What are some layering and partitioning considerations? </li></ul>