Explore

UPU-B Methodology

This document teaches you want you need to know to create hand in 3 for the Mobile App Capstone Course which is the Technology Project Plan Document.

Background materials:

The origin of Unified Process: The Software Crisis:

⁠

https://www.dropbox.com/scl/fi/u508eyig6azcnk3480f0a/Software-Engineering-and-looming-software-crisis.pptx?rlkey=nw6ujktsc6gscufwobvw15sf9&st=cbjpan3q&dl=0⁠

⁠

How Unified Process Works

⁠

https://youtu.be/04zCLEb6_NI⁠

⁠

https://youtu.be/Ok0N3tcfbzk⁠

⁠

Lexical Analsys:

https://youtu.be/DnCYcvRL9xg⁠

⁠

UPU-B Methodology

⁠

The marketing plan is the driver of your Entire Product Development Plan.

Methodology for developing iOS App Products including the elements of the Product Design:

- the UI Screens : The Screen is the user’s experience of the System

Code Base: Let’s focus on Android Kotlin: UML Diagrams

, and Data Model Using Unified Process, UML, and BPEL

Lab Notebook: How to make the Technology Planning Document for your Capstone Project.

A high level overview of our entire Capstone course could be called: PRODUCT DEVELOPMENT.

**Objective**: This lab focuses on teaching the process of designing and developing iOS app screens using the Unified Process (UP), UML (Unified Modeling Language), and BPEL (Business Process Execution Language). The goal is to create an efficient design flow from use case identification to screen development and code hierarchy.

### **1. Unified Process (UP) Overview**

The Unified Process is a software development methodology that emphasizes iterative development, architecture-centric approaches, and risk-driven models. UP divides the development into four phases:

- **Inception**: Define the scope, key use cases, and risks. - **Elaboration**: Refine the use cases, establish the architecture, and mitigate risks. - **Construction**: Build the product through incremental iterations. - **Transition**: Finalize the product and deploy it to users.

In this lab, we focus on the **Elaboration** and **Construction** phases, as these are where we transform requirements into design artifacts (UML diagrams) and implement them in code (iOS app screens).

---

### **2. UML for Use Case Identification**

UML is instrumental in defining and modeling the functional aspects of an iOS app. To begin, we capture the user interactions through **Use Case Diagrams**.

#### **Steps**: - **Identify Actors**: Actors are entities that interact with the app (e.g., a user or external system). - **Define Use Cases**: Use cases describe how actors interact with the system. Each use case represents a function the app must perform.

**Example**: For an iOS app that manages a to-do list, the actors and use cases might be:

- **Actor**: User - **Use Cases**: - View To-Do List - Add To-Do Item - Delete To-Do Item - Mark Item as Completed

#### **Use Case Diagram**: [Simple example UML diagram could be drawn here.]

- **Actor**: User - (1) View To-Do List - (2) Add To-Do Item - (3) Delete To-Do Item - (4) Mark Item as Completed

At this stage, the **inception** phase of UP is complete. We now move into **elaboration**, where we convert these use cases into **UML sequence diagrams** and **class diagrams**.

---

### **3. UML Sequence and Class Diagrams**

#### **Sequence Diagram**: A sequence diagram shows how objects interact in a time-sequenced fashion for each use case. This helps us understand the flow of information between different classes and the order of operations.

For the "Add To-Do Item" use case, the sequence diagram might show:

1. The user interacts with the "Add Item" button. 2. The app displays an "Add Item" form. 3. The user inputs the task and confirms. 4. The app saves the new task to the database.

**Diagram Description**:

- **User** → **AddItemViewController** → **TaskManager** → **Database**.

#### **Class Diagram**: Once interactions are clear, a class diagram is created to outline the key components of the system.

In this example, the primary classes might be:

- **Task**: Represents an individual task with attributes like `title`, `description`, `dueDate`, and `isCompleted`. - **TaskManager**: Handles the logic of adding, updating, and deleting tasks. - **AddItemViewController**: Manages the user interface for adding tasks.

**Attributes and Methods**:

- `Task` class: - Attributes: `title: String`, `description: String`, `dueDate: Date`, `isCompleted: Bool`. - Methods: `markAsComplete()`, `delete()`. - `TaskManager` class: - Methods: `addTask()`, `deleteTask()`, `updateTask()`.

At this point, we have a solid conceptual foundation for our app.

---

### **4. Mapping Use Cases to Code Hierarchy Using BPEL**

BPEL (Business Process Execution Language) is typically used in orchestrating services in a workflow, but it can be repurposed here to **design the code hierarchy** by mapping use cases to specific app components. This mapping defines how the flow of the application is handled programmatically.

#### **Process Flow in BPEL Terms**: 1. **Invoke User Interaction**: When the user triggers a use case, like "Add To-Do Item," the app's UI responds. 2. **Invoke Logic Layer (TaskManager)**: After interacting with the view, the logic is handled by the TaskManager, which handles adding or updating tasks. 3. **Data Management (Database)**: BPEL manages data persistence, where tasks are stored or updated in a database. 4. **Return to UI**: The updated state is returned to the UI (e.g., the to-do list updates with the new item).

#### **BPEL Process Example**:

```xml <process name="AddTaskProcess"> <receive operation="UserAddTask" /> <invoke operation="AddTaskToTaskManager" /> <invoke operation="SaveTaskToDatabase" /> <reply operation="UpdateUI" /> </process> ```

**Explanation**: - **Receive**: Triggered by the user adding a task. - **Invoke (TaskManager)**: The request is processed by the TaskManager class. - **Invoke (Database)**: The task is saved into a local or cloud database. - **Reply**: The UI is updated to reflect the new state (i.e., the new task is displayed).

This process illustrates the hierarchical structure where: - **User interaction** → **Controller (ViewController)** → **Logic (TaskManager)** → **Data (Database)**.

---

### **5. Developing the App Screens (iOS Interface)**

With the code hierarchy established using BPEL and the UML diagrams as a guide, we now proceed to create the iOS app screens.

#### **iOS App Structure**: - **Model-View-Controller (MVC)** pattern: - **Model**: Task and TaskManager classes. - **View**: The screens, such as the To-Do List and Add Item screen. - **Controller**: ViewControllers managing the UI, e.g., AddItemViewController.

#### **Steps for Screen Design**: 1. **Storyboard**: Use Xcode's Interface Builder to design the user interface. - Create the main storyboard with the following views: - **To-Do List ViewController**: Displays the list of tasks. - **Add Item ViewController**: Provides a form for adding new tasks.

2. **Interface Elements**: - **To-Do List View**: - A `UITableView` to list tasks. - Navigation bar with an "Add" button to invoke the AddItemViewController. - **Add Item View**: - `UITextField` for entering the task title. - `UITextView` for task description. - `UIDatePicker` for setting the due date. - A "Save" button to add the task to the TaskManager.

3. **Controller Implementation**: - In **AddItemViewController**: - Implement functionality to gather input from the user and pass the new task to the TaskManager.

---

### **6. Testing and Iteration (Construction Phase)**

Once the app screens are developed and connected to the TaskManager, we test the app:

- **Test Cases**: - Verify that tasks can be added and appear in the to-do list. - Ensure tasks can be marked as complete or deleted. - Validate the UI flow between different views.

Any issues identified in the test phase are addressed by iterating through the design and development process. These iterations continue until all use cases function as intended.

---

### **Conclusion**

By applying the Unified Process and UML diagrams, we have modeled the key aspects of an iOS app based on its use cases. Furthermore, by using BPEL, we created a clear hierarchy for mapping these use cases to the underlying code structure. The final outcome is a functional iOS app with a well-defined architecture and UI flow.

This process highlights the importance of disciplined design methodologies in app development, resulting in a product that is both user-friendly and maintainable.

---

**End of Lab Notebook**.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.