1 / 30

Chapter 8: Case Study

Chapter 8: Case Study. FCAPS System (Part II). Iteration 2: Identifying Structures to Support Primary Functionality. This section presents the results of the activities that are performed in each of steps of ADD

dennisrogers
Download Presentation

Chapter 8: Case Study

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. Chapter 8: Case Study FCAPS System (Part II)

  2. Iteration 2: Identifying Structures to Support Primary Functionality • This section presents the results of the activities that are performed in each of steps of ADD • The goal in second iteration is to reason about the units of implementation, which affect team formation, interfaces, and the means by which development tasks may be distributed, outsourced, and implemented in sprints

  3. Step 2: Establish iteration goal by selecting drivers • The goal of this iteration is to address the general architecture concern of identifying structures to support primary functionality • Identifying these elements is useful not only for understanding how functionality is supported CRN-3 – allocation of work to members of development team • In this second iteration, besides CRN-3, the architect considers the system’s primary use cases:- • UC-1 • UC-2 • UC-3

  4. Step 3: Choose one or more elements of the system to refine • The elements that will refined in this iteration are the modules located in the different layers defined by the two reference architectures from the previous iteration • Support of functionality in this system requires the collaboration of components associated with modules that are located in the different layers

  5. Step 4: Choose one or more design concepts that satisfy the selected drivers • The folowing table summarizes the design decisions. The words in bold in the following table refer to architectural pattern

  6. Step 4: Choose one or more design concepts that satisfy the selected drivers • The folowing table summarizes the design decisions. The words in bold in the following table refer to architectural pattern

  7. Step 5: Instantiate Architectural Elements, Allocate Responsible, & Define Interfaces • The folowing table summarizes the instantiation design decision

  8. Step 5: Instantiate Architectural Elements, Allocate Responsible, & Define Interfaces • The folowing table summarizes the instantiation design decision

  9. Step 6: Sketch views and record design decisions • As a result of the decisions made in step 5, several diagram are created • Figure 8.5 shows an initial domain model for the system • Figure 8.6 shows the domain objects that are instantiated for the use case model • Figure 8.7 shows a sketch of a module view with modules that are derived from the business objects & associated with the primary use cases

  10. Step 6: Sketch views and record design decisions 0. * generates • Event • - date • - payload • - severity • - type 0. * • Time Server • - deviceName • - ipAddress • - model 1 Region - name parent 1. * 0. * acknowledges Fig. 8.5 Initial domain model 1 Configuration - configurationParameters • Performance Data • - delay: DataSet • - jitter: DataSet • - offset: DataSet 1 • User • - login • - password • - permissions • - type

  11. Step 6: Sketch views and record design decisions Fig. 8.6 Domain objects associated With the use case model <<domain object>> Fault Detection <<domain object>> Network Status Monitoring <<domain object>> Event History Responsibilities UC-2 Responsibilities UC-1 Responsibilities UC-3 <<domain object>> Time Server Management <<domain object>> Time Server Management <<domain object>> System Access Responsibilities UC-4 Responsibilities UC-5 UC-6 Responsibilities UC-10 <<domain object>> Performance Data & Info. Display <<domain object>> Performance & Data Collection <<domain object>> User Management Responsibilities UC-8 UC-9 Responsibilities UC-7 Responsibilities UC-11

  12. Step 6: Sketch views and record design decisions Client Side <<layer>> Presentation CS NetworkStatusMonitoringView <<layer>> Business Logic CS NetworkStatusMonitoringController <<layer>> Data CS RequestManager

  13. Step 6: Sketch views and record design decisions Fig. 8.7 Modules that support the primary use cases Server Side <<layer>> Service SS <<facade>> RequestService <<layer>> Business Logic SS TopologyController DomainEntities TimeServerEventsController DataCollectionController <<layer>> Data SS EventDataMapper RegionDataMapper TimeServerDataMapper TimeServerController

  14. Step 6: Sketch views and record design decisions

  15. Step 6: Sketch views and record design decisions

  16. Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose • The decision made in this iteration provided an initial understanding of how functionality is supported in the system • The modules associated with the primary use cases were identified by the architect, and modules associated with the rest of the functionality were identified by another team member

  17. Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose

  18. Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose

  19. Iteration 3: Addressing Quality Attribute Scenario Driver (QA-3) • This section presents the results of the activities that are performed in each of the step of ADD in the third iteration of the design process • This iteration focuses on just one of these quality attributes scenarios

  20. Step 2: Establish Iteration Goal by Selecting Drivers • For this iteration, the architect focuses on the QA-3 quality attribute scenario: A failure occurs in managemnt system during operation. The management system resumes operation in less than 30 seconds

  21. Step 3: Choose one or more elements of the system to failure • For this availability scenario, the elements that will be refined are the pyhsical nodes that were identified during the first iteration:- • Application server • Database server

  22. Step 4: Choose one or more design concepts that satisfy the selected drivers • The design concepts used in this iteration are the following:

  23. Step 5: Instantiate Architectural Elements, Allocate Responsibilities, & Define Interfaces • The instantiation design decisions are summarized in the following table:-

  24. Step 6: Sketch views and record design decisions • The figure shows a refined deployment diagram that includes the introduction of redundancy in the system Fig. 8.8 Refined deployment diagram Server1: ApplicationServer <<JDBC>> <<replicated>> LoadBalancer Pc: Workstation <<replicated>> Database Server <<HTTP>> Server2: ApplicationServer <<JDBC>> <<SNMP>> <<replicated>> :TrapReceiver Device1: TimeServer Relocatable IP address

  25. Step 6: Sketch views and record design decisions • The following table describes responsibilities for elements that have not been listed previously (in iteration 1)

  26. Step 6: Sketch views and record design decisions • The UML sequence diagram show in Fig 8.9 illustrates how the TrapReceiver that was introduced in this iteration exchanges messages with other elements shown in the deployment diagram to support UC-2 (detect fault), which is associated with both QA-3 (availability) and QA-1 (performance) :NetworkDevice :TrapReceiver :ApplicationServer Pc: UserWorkstation trap() transformAndEnqueue(Event) Fig. 8.9 Sequence diagram consume() publish() event() updateView()

  27. Step 7: Perform analysis of current design & review iteration goal & achievement of design purpose • In this iteration, important design decisions have been made to address QA-3, which also impacted QA-1. • The following table summarizes the status of the different drivers and the decisions that were made during the iteration

  28. Step 7: Perform analysis of current design & review iteration goal & achievement of design purpose

  29. Step 7: Perform analysis of current design & review iteration goal & achievement of design purpose

  30. Summary • In this chapter, we presented an example of using ADD to design a greenfield system in a mature domain • We illustrated three iterations with different foci: addressing a general concern, addressing functionality, and addressing one key quality attribute scenario7 • The example also demonstrates how architectural concerns, primary use cases, and quality attributes scenarios can be addressed as part of architectural design • In a real system, more iterations would be necessary to create a complete architecture design by addressing other scenarios with high priority

More Related