ANALYSIS - II

1. ANALYSIS - II ANALYSIS REQUIREMENT DESIGN IMPLEMENTATION TEST

2. Use Case Realization • Collaboration within the analysis model. • Describes how a specific usecase is realized and performed in terms of analysis classes and their interacting objects. • Focus is on the functional requirements. • Postpones the handling of the non-functional requirements until subsequent design and implementation activates by designating them as special requirements on the realization.

3. Use case realization - contains Use Case Realization - Analysis Flow of Events-Analysis Class Diagrams Interaction Diagrams Special Requirements Analysis Class

4. Class Diagrams • Analysis classes and objects. • The above can exist in several usecase realizations. • Responsibilities, attributes and associations of a specific class are often relevant to only one usecase realization. • Coordinate all the requirements on a class and its objects that different use-case realization may have.

5. Class Diagram

6. Interaction Diagram • A Sequence of action in a usecase begins when an actor invokes the usecase by sending some form of message. To the System. • Actions (Collaboration Diagram): Focus on finding requirements requirements and responsibilities on object and NOT to find detailed and chronological sequence of action. • Boundary object receives message from actor. • Boundary object sends a message to some other object inside the system

7. Collaboration Diagram - Ex

8. Creation & Termination of analysis objects • Boundary Object: • Need not be specific to one usecase realization. • Boundary objects are often created and terminated within a single usecase realization • Entity Objects • Not Specific to one usecase realization • Long Lived and participates in several usecase realizations before it is terminated.

9. Creation & Termination of analysis objects • Control Objects: • Encapsulates control related to a specific usecase. • Hence created when the usecase starts and terminated when the usecase ends. • Exceptions : • Control Classes participate in more than one usecase_r. • Several control classes participate in one usecase_r. • Usecase_r does not use any control class at all.

10. Flow of Events • Additional text used to explain the Collaboration Diagram. • Pertains particularly to Control Objects • Does not mention any of the object responsibilities, attributes and associations.

11. Special Requirements • Textual description that collect all non-functional requirements. • Identified primarily during Requirements, however some may be new or derived requirements found during the analysis work flow. • Examples: • When a buyer asks to see view received invoices, it should not take more than 0.5 seconds to show the invoice on the Screen. • Invoice should using the SET Standard.

12. Analysis Packages • Means of organizing the artifacts of the analysis model in manageable pieces. • Consists of analysis classes, usecase realization-analysis and other service packages. • They are highly cohesive and loosely coupled.

13. Analysis Packages - Characteristics • Represent a separation of Analysis Concern. • Created based on functional requirements. • Recognizable by people with domain knowledge. • Likely to become subsystems in two top layers of Design Model.

14. Service Packages • Set of service to the customer. A customer requires a suitable mix of services to give its users the necessary usecase to carry out the business. • A service represents a coherent set of functionally related actions – a package of functionality. • Usecases are for users and services are for customers. • Used at lower level of analysis package hierarchy to structure the system according to the services it provides. • Are reusable.

15. Architectural Description • Architectural description of the Analysis Model depicting its architecturally significant artifacts: • Decomposition of Analysis Model into analysis packages. • Key analysis classes. • Usecase realization that realizes some important and critical functionality.

16. Workflow – Architectural Analysis • The purpose of the architectural analysis is to outline the analysis model and architecture by identifying analysis packages, obvious analysis classes and common analysis requirements.

17. Identifying Analysis Packages • An initial identification of analysis package is naturally done based on the functional requirement and problem domain. • They can either be identified initially by a way of dividing the analysis work or to be found as the model evolves and “grows” into a large structure which needs to be decomposed.

18. Identifying Analysis Packages • Since we capture functional requirements as usecases a straight way to analyze a analysis package is to allocate the main portion of a number of usecases to a specific package and realize the corresponding functionality within the package. • Usecases required to support a specific business process. • Usecases required to support a specific actor of the system. • Usecases that are related.

19. Handling Commonality • It is often the case that commonalities can be found among packages as identified in the proceeding section. An appropriate way to handle this is to extract the shared class and put it into its own package or other packages and let other packages be dependent on this more general package or class.