1 / 40

Software Architecture & Design

Software Architecture & Design. 6CCS3SAD / 7CCSMDAS Dr Kevin Lano. Session 2: A Simple Process for Architecture Design. January 21 st , 2019. Learning Outcomes. At the end of this session you should be able to: Design simple three-tiered architectures in a systematic way. Context.

babu
Download Presentation

Software Architecture & Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Architecture & Design 6CCS3SAD / 7CCSMDAS Dr Kevin Lano

  2. Session 2:A Simple Process for Architecture Design January 21st, 2019

  3. Learning Outcomes At the end of this session you should be able to: • Design simple three-tiered architectures in a systematic way.

  4. Context • Last week • Basic architectural elements • Simple architectures • UML2 notation for architectures • BUT: How do we get to an architecture? • Today: A simple design process • Based on:Cheesman and Daniels: UML Components. Addison Wesley 2001.

  5. Warning • Architectural decisions mostly driven by quality requirements • Performance, security, reliability, maintainability, evolvability, etc. • Different requirements lead to different architectures • Today • Focus on evolvability and maintainability

  6. 3tier Architectures Presentation Layer ... Swing Client Web Client Web Server Business Layer Application Server Data Management Layer Database Server

  7. Refined View Presentation Layer User Interface Dialog Logic Business Layer System Services Business Objects Data Management Layer Database Server

  8. Development Process Business Requirements Requirements Analysis Use Cases Business Concept Model Specification Provisioning Assembly Component Specs & Architecture Components Test Deployment This is a limited view. Refer to the book for a more precise perspective.

  9. Requirements Analysis Domain Knowledge Requirements Requirements Analysis Develop Business Concept Model Develop Use Case Model Business Concept Model Use Cases

  10. Business Concept Model • Models all concepts in domain and their relations • Concepts as classes, relations as associations • Rules • Be generous • Add stuff that may not make it into the application, can always remove later! • At this stage, don’t care about attributes and other details • Not architecturally relevant, will add later

  11. Business Concept Model (2) 1 Hotel Chain Clerk 1..* Hotel 1..* 1 contactedHotel 1 * 1 Reservation * 1..* * 1 * Customer Room * 0..1 1 1 * * 1 0..1 Room Type Address 1 0..1 Bill 1 0..1 Payment

  12. Requirements Analysis Domain Knowledge Requirements Requirements Analysis Develop Business Concept Model Develop Use Case Model Business Concept Model Use Cases

  13. Use Cases • Use case • A sequence of actions providing value to an actor • Scenario • Sequence of steps within a use case • Alternate user and system steps

  14. Use Cases (2) Reservation System Make Reservation Guest Cancel Reservation Update Reservation

  15. Use Cases (3) • Each use case has a scenario, e.g.: Make Reservation Guest selects hotel, dates,and room type System provides availabilityand price System makes reservation

  16. Specification Requirements Analysis Business Concept Model Use Cases Specification Component Identification Component Interaction We will come back to this at the end of term Component Specification

  17. Recall: Refined View Presentation Layer User Interface Dialog Logic Business Layer (cf: Session bean) System Services Business Objects (cf: Entity Bean) Data Management Layer Database Server

  18. System and Business Interfaces System Interfaces Business Layer System Services Business Interfaces Business Objects Business Component Business Component System Component System Component

  19. Component Identification Business Concept Model Use Cases Component Identification Develop Business Type Model Identify Business Interfaces Identify System Interfaces Create Initial Architecture Business Type Model Business Interfaces Initial Architecture System Interfaces

  20. Identify System Interfaces • Provide operations required to implement use cases • Only system steps of use cases • Only what is needed from dialog logic (this may cache information!) • One interface per use case • Later these may be rationalised if there are common steps between different use cases

  21. Identify System Interfaces (2) Make Reservation Make Reservation <<interface>> IMakeReservation getHotelDetails() getRoomInfo() makeReservation() Guest selects hotel, dates,and room type System provides availabilityand price System makes reservation

  22. Break

  23. Component Identification Business Concept Model Use Cases Component Identification Develop Business Type Model Identify Business Interfaces Identify System Interfaces Create Initial Architecture Business Type Model Business Interfaces Initial Architecture System Interfaces

  24. Business Type Model • Refinement of Business Concept Model • Remove irrelevant concepts • Merge / Divide concepts • Identify core types

  25. Business Type Model (2) 1 Hotel Chain Clerk 1..* Hotel 1..* 1 contactedHotel 1 * 1 Reservation * 1..* * 1 * Customer Room * 0..1 1 1 * * 1 0..1 Room Type Address 1 0..1 Bill 1 0..1 Payment

  26. Identify Core/Dependent Types • Core types • Directly correspond to primary business information • Will form basis for component identification • Dependent types • Instances only make sense in connection to a core type instance • Category types • Dependent types that classify other types

  27. Identify Core/Dependent Types (2) • Core types • Business identifier • No mandatory associations (except to category type)

  28. Identify Core/Dependent Types (3) 1 1 Hotel 1 Reservation 1..* * 1 * Customer Room * 0..1 * * 1 Room Type 1 1..*

  29. Identify Core/Dependent Types (4) 1 <<core>> Hotel 1 1 <<type>> Reservation 1..* * <<core>> Customer <<type>> Room 1 * * 0..1 * * 1 <<category>> Room Type 1 1..*

  30. Component Identification Business Concept Model Use Cases Component Identification Develop Business Type Model Identify Business Interfaces Identify System Interfaces Create Initial Architecture Business Type Model Business Interfaces Initial Architecture System Interfaces

  31. Identify Business Interfaces (2) • One interface per core type • Spans a “region of responsibility” over dependent types • Associations between regions • Try to limit number of these • Where they remain: allocate responsibility to one interface • Use arrow notation to show on diagram

  32. Identify Business Interfaces 1 <<interface>> IHotelMgt <<core>> Hotel 1 1 <<type>> Reservation 1..* * <<core>> Customer <<type>> Room 1 * * 0..1 * * 1 <<category>> Room Type <<interface>> ICustomerMgt 1 1..*

  33. Component Identification Business Concept Model Use Cases Component Identification Develop Business Type Model Identify Business Interfaces Identify System Interfaces Create Initial Architecture Business Type Model Business Interfaces Initial Architecture System Interfaces

  34. Initial System Architecture • Need to define components • Starting assumption: • One business component per business interface • One system component for all use cases • Key question for decisions: • Which functions belong together? • Will need to evolve or be exchanged together, so should be in one component

  35. Initial System Architecture (2) IMakeReservation IBilling ICancelReservation ICustomerMgt IUpdateReservation IHotelMgt Reservation System Billing System Customer Manager Hotel Manager

  36. Specification Requirements Analysis Business Concept Model Use Cases Specification Component Identification Component Interaction We will come back to this at the end of term Component Specification

  37. Component Interaction • Need to find operations that should be in business interfaces • Analyse how system components need to interact with business components • For each system-interface operation, draw an interaction diagram • Identify business operations • Identify parameters and return values for all operations

  38. Component Interaction (2) makeReservation() /IMakeReservation : ReservationSystem 2. makeReservation() 1. getCustomerMatching() 3. notifyCustomer() /IHotelMgt /ICustomerMgt <<interface>> IMakeReservation ... +makeReservation (res: ReservationDetails, cs: CustomerDetails) : String <<interface>> IHotelMgt ... +makeReservation (res: ReservationDetails, csID: CustomerID) : String <<interface>> ICustomerMgt ... +getCustomerMatching (cs : CustomerDetails) : CustomerID +notifyCustomer (csID : CustomerID, message : String) : void

  39. Summary • A systematic approach to defining simple architectures • There’s more to it! • We have not considered: • Formal specification • Implementation of components • See the book for more details • Severe limitations • Mainly focused on evolvability • Only for three-tier architectures • Not sure how well it scales up • BUT: A good starting point for any architecture design!

  40. Coming Up • Compound components, simple and complex architecture styles • Implementation of components and component architectures • Beyond basic Java classes • Complex forms of communication • Domain-specific modelling issues

More Related