Chapter 6 View Alignment Techniques and Method Customization (Part III)

1. Chapter 6View Alignment Techniques and Method Customization(Part III) Object-Oriented Technology From Diagram to Code with Visual Paradigm for UML Curtis H.K. Tsang, Clarence S.W. Lau and Y.K. Leung McGraw-Hill Education (Asia), 2005

2. Method Creation: A Case Study • The use case driven approach has been very popular and widely adopted over the past few years. • It has also become a core component of the Unified Modeling Language (UML).

3. Method Creation: A Case Study • While object-oriented design is much more sophisticated than the traditional structured approach, practitioners often face the following difficulties: • Use cases are used to specify the requirements of a system. While users can tell us their business activities and processes, they cannot tell us which parts should be computerized and which parts should remain as manual procedures. • Object identification is not an easy task. • The realization from a use case to a set of sequence diagrams (with a collaborative set of objects in them) is another difficult task.

4. Seven Steps of Method Creation Process • The Activity Analysis Approach uses UML as the notation, the Unified Process as the process, and View Alignment Techniques for the techniques part. • We have named the approach as the Activity Analysis Approach because activity analyses are performed at three different levels: business workflow, use case and scenario levels. • Business workflow analysis – the workflows of a company/organization are represented by swimlane activity diagrams at different levels of abstraction.

5. Seven Steps of Method Creation Process (cont’d)

6. Step 1: Configure the Process • a. Determine the suitability of the development phases, number of iterations and workflows of the development process.The designer could start with a model based on the readily available information and then develop other related models by applying the View Alignment Techniques. • For the Activity Analysis Approach, we would like to keep the case study precise and concise, so only Business Modeling, Requirements, Analysis and Design workflows will be included.

7. Step 1: Configure the Process (cont’d) • b. Determine the artifacts and deliverables for each workflow. • The architecturally significant use cases in the use case schedule should be developed first. • At the end of each iteration, a prototype should be produced for the selected use case(s) and there is major subsystems integration for each of the development phases.

8. Step 1: Configure the Process (cont’d)

9. Step 1: Configure the Process (cont’d)

10. Step 2: Select Models for the Workflow under Development • In the previous step, we decided to include the Business Modeling, Requirements, Analysis and Design Workflows in each of the development iteration. • The first workflow we need to start with, according to the order of the development iteration, is the Business Modeling workflow. • Need to analyze and determine the business activities before deciding on the system’s requirements. • Need to know the standards, terminology and general practice in the industry.

11. Step 2: Select Models for the Workflow under Development (cont’d) • Thus we need to have two analysis blocks here in the Business Modeling Workflow. • Activity Diagrams are an excellent analysis tool, while textual analysis is widely used to reveal static information such as documentation, standards or user guides of legacy systems. • Business Workflow Analysis. The business process (workflow) of a company is analyzed using activity diagrams. The primary goal is to identify the candidate business activities for automation by software systems.

12. Step 2: Select Models for the Workflow under Development (cont’d) • Textual Analysis. The business process (workflow) of a company is analyzed using activity diagrams. The primary goal is to identify the candidate business activities for automation by software systems.

13. Step 3: Apply Model Elaborator • In this step, we apply the Model Elaborator to complete the workflow. • We can then identify use cases from both the Business workflow analysis and Textual Analysis which can be used straight away for the next workflow – Requirements. • We will use the use case diagram as the main model for the Requirements Workflow. Thus, the Linked Elements are a list of candidate use cases identified from the business workflow and textual analysis.

14. Step 3: Apply Model Elaborator (cont’d) • However, for very complex problems involving many activities, it might be necessary to develop a lower-level activity diagram to get a zoom-in view to understand what functions these activities perform.

15. Step 3: Apply Model Elaborator (cont’d)

16. The Business Modeling Workflow

17. The Business Modeling Workflow (cont’d)

18. The Business Modeling Workflow (cont’d)

19. Step 4: Identify Linked Elements • At this stage, we identify the Linked Elements (or discover new requirements) for the next workflow and proceed with the step below. • We have now identified the candidate use cases from the business workflow and possibly from the textual analysis. The terminologies and descriptions used for naming the use cases should be consistent and documented in the data dictionary later. • Once we have found the Linked Elements extracted from the model(s) in this workflow, we can use the Linked Elements to derive the model for the next workflow - Requirements.

20. Step 5: Apply the Model Transitor • Navigate to the next workflow and select appropriate models to work with this workflow. • Make use of the Linked Elements extracted from the model of the last workflow to derive the new models for this workflow. • At this point, the designer can develop the use case diagram for the Requirements workflow.

21. Step 6: Apply the View Aligner • Having completed the first workflow (Business Modeling), we should then focus on the next workflow (Requirements). Because we do not have a lot of completed models, we do not apply the View Aligner at this point.

22. Step 7: Develop Next Workflow • Having finished the Business Modeling Workflow, we are ready to proceed to the Requirements Workflow by repeating Steps 5 to 7 of the process of applying the View Alignment Techniques until all the workflows have been completed.

23. Transiting to Next Workflow: Requirements • The system requirements are recorded by use case diagrams, use case descriptions and actor specifications. • We can start with the list of business activities that have been identified for computerization in the business modeling and analysis workflow, and prepare a problem statement (use case level) for the system. • The problem statement will then be used for identifying actors and use cases.

24. Transiting to Next Workflow: Requirements (cont’d) • Two analyses are involved in the Requirements Workflow: • the Use Case Analysis • the Domain Analysis • Repeat Steps 4 and 6.

25. Workflow for Requirements

26. Workflow for Requirements (cont’d)

27. Workflow for Requirements (cont’d)

28. Workflow for Requirements (cont’d)

29. Step 7: Transit to Next Workflow – Analysis • The purpose of the analysis workflow is to identify the classes and objects of the system from the models of the requirements workflow and the ways in which the users invoke the use cases. • It is generally difficult to ascertain sequence information from the use case description. The activity diagrams will enable us to do so effectively. • We can see that the transition from Requirements to Analysis is natural, and the creation of activity diagrams from use case descriptions is also straightforward through the use of the Linked Elements between them.

30. Repeating Steps 5 and 6 • The Roadmap for the Analysis Workflow contains three analyses. • Domain analysis (class level) • Static modeling • System modeling

31. The Analysis Workflow (cont’d)

32. The Analysis Workflow (cont’d)

33. The Analysis Workflow (cont’d)

34. The Analysis Workflow (cont’d)

35. Step 7: Transit to Next Workflow - Design • The design workflow is about conducting behavioral modeling and analysis so that we can progress from the stage of getting a detailed understanding of not only what the problem is, but also how the problem is going to be solved. • At this point, we will proceed from a detailed description of the system’s external behavior to the design of the system’s internal logic.

36. Repeating Steps 4 to 6 • The Design Workflow contains two analyses. They are the Scenario Analysis and State Analysis. • The first steps of the Scenario Analysis is concerned with the design of the realization of each action state in the activity diagram, representing a use case, using a collaboration diagram. • The collection of all these collaboration diagrams representing action states forms a detailed Model/View and Control (MVC)-level sequence diagram. • The control object(s) or subsystems will, in turn, be represented by a state diagram. • To ensure traceability and consistency of models, applications of view aligners are necessary.

37. The Design Workflow

38. The Design Workflow (cont’d)

39. The Design Workflow (cont’d)

40. The Design Workflow (cont’d)