Chapter 2 (Part1) : Business Process and Functional Modeling PDF

**Chapter 2 (Part1) : Business Process and Functional Modeling** \* Functional Models describe business processes and the interaction of an information system with its environment. \* In object-oriented system development two types of model are used to describe the functionality of an information...

**Chapter 2 (Part1) : Business Process and Functional Modeling** \* Functional Models describe business processes and the interaction of an information system with its environment. \* In object-oriented system development two types of model are used to describe the functionality of an information system : **use-case diagram / activity diagram** \* Use-case diagram : describe basic functions of information system \* Activity diagram : support the logical modeling of business processes and workflow. \* Both can be used to describe the current as-is system and the to-be system being developed. - Models are logical; i.e., independent of how they are implemented (manual or computerized). - Develop use-cases from the requirements - Develop activity diagrams from the use-cases - Analyst can employ use cases and the use-case diagram to better - use-case diagram provides a simple, - A use-case diagram is drawn when gathering and defining - **Element of use-case diagram :** - Activity diagrams depict the sequence of these - Diagrams are abstract and describe processes in general - They model behavior independent of objects - Can be used for any type of process - Elements of an Activity Diagram - Object Nodes: represent the flow of information - Control Flows: model execution paths - Object Flows: model the flow of objects - Control Nodes: 7 types - Control Nodes - **Initial node:** the beginning of the set of actions/activities - **Final-activity node**: stops all actions/activities - **Final-flow node**: stops one execution path but allows others to continue. - **Decision node**: represents a test to determine which path to use to continue (based on a guard condition). - **Merge node**: rejoins mutually exclusive execution paths - **Fork node**: separates a single execution path into one or more parallel paths. - **Join node**: rejoins parallel execution paths. - **Swim lanes** - Used to assign responsibility to objects or individuals who actually perform the activity - Represents a separation of roles among objects - Can be drawn horizontally or vertically - **Guidelines for Activity Diagrams :** - Creating an Activity Diagram - Choose a business process identified previously - Review the requirements definition and use-case diagram - Review other documentation collected thus far - Identify the set of activities used in the business Process - Identify control flows and nodes - Identify the object flows and nodes - Lay out & draw the diagram (minimize crossing lines) **Use Cases** - The primary driver for all UML diagramming techniques - Depicts activities performed by the users - Describe basic functions of the system: 1-What the user can do 2-How the system responds - Use cases are building blocks for continued design activities -  Each use-case describes 1 and only 1 function. **Elements of a Use Case Description** Overview: Name, ID Number, Type, Primary Actor, Brief Description, Importance Level, Stakeholder(s), Trigger(s) Relationships: - Association: Communication between the use case and the actors - Extend: Extends the functionality of a use case - Include: Includes another use case - Generalization: Allows use cases to support inheritance Flow of events - Normal flow: the usual set of activities - Sub-flows: decomposed normal flows to simplify the use-case - Alternate or exceptional flows: those not considered the norm Optional characteristics (complexity, time, etc.). **Use Case Writing Guidelines** 1\. Write in the form of subject-verb-direct object 2\. Make sure it is clear who the initiator of the step is 3\. Write from independent observer's perspective 4\. Write at about the same level of abstraction 5\. Ensure the use case has a sensible set of steps 6\. Keep the use case as simple as possible 7\. Write repeating instructions after the set of steps to be repeated. **Creating Use-Case Descriptions** 1\. Pick a high priority use-case and create an overview: \- List the primary actor \- Determine its type (overview or detail; essential or real) \- List all stakeholders and their interests \- Determine the level of importance of the use-case \- Briefly describe the use-case \- List what triggers the use-case \- List its relationship to other use-cases 2\. Fill in the steps of the normal flow of events required to complete the use-case 3\. Ensure that the steps listed are not too complicated or long and are consistent in size with other steps 4\. Identify and write the alternate or exceptional flows 5\. Carefully review the use-case description and confirm that it is correct 6\. Iterate over the entire set of steps again **Verifying & Validating a Use-Case :** structural and behavioral modeling Utilize a walkthrough\* Perform a review of the models and diagrams created so far Performed by individuals from the development team and the client (very interactive) Facilitator: schedule and set up the meeting Presenter: the one who is responsible for the specific representation being reviewed Recorder (scribe) to take notes and especially to document errors. **Rules for Verification & Validation** 1\. Ensure one recorded event in the flows of the use-case description for each action/activity on the activity diagram 2\. All objects in an activity diagram must be mentioned in an event of the use-case description 3\. The sequence of the use-case description should match the sequence in the activity diagram 4\. One and only one description for each use-case 5\. All actors listed in a use-case description must be shown on the use-case diagram 6\. Stakeholders listed in the use-case description may be shown on the use-case diagram (check local policy) 7\. All relationships in the use-case description must be depicted on the use-case diagram 8\. All diagram-specific rules must be enforced