1. 1 ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #1

2. Background Brief Dr. Suronapee Phoomvuthisarn PhD in CSE, University of New South Wales, 2011 National ICT Australia (2008 - 2011) Research interests in software architecture Service Economics, Cloud Computing Work History: Mahanakorn University of Technology (Since 2007) Position: รองคณบดีฝ่ายกิจการนักศึกษาและ ประชาสัมพันธ์ http://www.it.mut.ac.th/personal/teacher/65-suronapee Email : suronape@mut.ac.thsuronape@mut.ac.th 2

3. Grading Policy 10% for class attendance 10% for assignments and quiz. 40% for midterm exam. 40% for final exam. 3

4. 4 Class Overview Class content is divided into 2 parts. Overview of object-oriented systems development and UML notation Use case diagram Activity diagram Class diagram Sequence diagram Android Programming basics Local database Remote database Application on cloud, tv, wearable etc.

5. 5 Object-oriented System Development Object-oriented systems development is a way to develop software by building self-contained modules or objects that can be easily replaced, modified, and reused. Software is a collection of discrete objects that encapsulate their data (data member, attribute, object data) and functionality (methods, operations) to model real-world “objects.”.

6. 6 Using Class to Create Objects Circle c1 = new Circle(…); Circle c2 = new Circle(…); Circle c3 = new Circle(…); * c1, c2, c3 are not UML notations.

7. 7 Example Class circle Attributes - x, y, radius Operations - draw(), setLocation(int x, int y), setSize(int radius) Java code public class Circle { private intx; private inty; private intradius; public void draw() {} public void setLocation(int x, int y) {} public void setSize(int radius) {} }

8. 8 Object-oriented System Development (2) In an OO system, everything is an object and each object is responsible for itself. Operations are the only way to change an object’s internal data (encapsulation).

9. 9 Object-oriented System Development (3) An object performs an operation when it receives a request (message) from other objects.

10. 10 Why Object Orientation Higher level of abstraction An object is a thing drawn from the vocabulary of the problem space of the solution space. OO supports abstraction at the object level, which encapsulate both data and functions. Encouragement of good programming techniques A class in an object-oriented system separates its interface (specification of what the class can do) from the implementation of that interface (how the class does what it does) Promotion of reusability

11. 11 UML UML (Unified Modeling Language) is a standard language for writing software blueprints. It is a very expressive language, addressing all the views needed to develop and deploy systems. UML does not specify a methodology or what steps to follow to develop an application.

12. 12 UML2 Diagrams Class diagram Object diagram Component diagram Composite structure diagram Use case diagram Sequence diagram Communication diagram State diagram Activity diagram Deployment diagram Package diagram Timing diagram Interaction overview diagram

13. 13 Building an Object-Oriented System Here is an example of how we use UML diagrams in each phase of the development. User Requirement Gathering System Analysis Designs And Development Application Deployment Use Case Diagram Activity Diagram Class Diagram Package Diagram Sequence Diagram Communication Diagram Object Diagram Component Diagram Deployment Diagram

14. 14 Type of Objects Inside a System Storage Application Users User Interface Objects Storage Access Objects Application Data Objects Depending of how the system is designed, there may be several types of the objects inside an application.

15. 15 Layered Architecture (1) For a complex system, there may be many objects interacting each other as a monolithic system. Layered architecture allows us to separating objects into groups by their duty inside the application. Common layers include View or user interface layer Business layer Access layer

16. 16 Layered Architecture (2) Storage Users View Layer Business Layer Access Layer

17. 17 Layered Architecture (3) MySQL Desktop Users Web Interface Business Layer MySQL Library Mobile (WAP) Mobile Users Oracle Oracle LibraryWeb Service Access

18. 18 Use Cases In the UML, you apply use cases to capture the intended behavior of the system you are developing, without having to specify how that behavior is implemented. A use case represents a functional requirement of your system. Use case study is done during User Requirement Gathering. Use cases provide a way for your developers to come to a common understanding with your system’s end users and domain experts.

19. 19 Use Cases From the perspective of a given actor, a use case carries out some tangible amount of work. You can apply use case for the whole system, a subsystem or even an individual class.

20. 20 Subject The subject is usually a system or subsystem.

21. 21 Names Every use case must have a unique name. A name can be a simple name or qualified name.

22. 22 Use Cases and Actors An actor commonly represents a human, a hardware device, or another system. In general, an actor represents a coherent set of roles that users of use cases play when interacting with these use cases. Actors may be connected to use cases only by association, each one possibly sending and receiving messages. All use cases and actors must be connected by association relationships.

23. 23 Use Cases and Flow of Events You can specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily. This is also called use case specification. When you write flow of events, you should include How and when the use case starts and ends. When the use cases interacts with the actors and what objects are exchanged. Basic flow and alternative flows of the behavior.

24. 24 Flow of Event Example Main flow of events. The use case starts when the system prompts the Customer for a PIN number. The Customer can now enter a PIN number via the keypad. The Customer commits the entry by pressing the Enter button. The system then checks this PIN number to see if it is valid. If the PIN number is valid, the system acknowledges the entry, thus ending the use case. Exceptional flow of events. The Customer can cancel a transaction at any time by pressing the Cancel button, thus restarting the use case. No changes are made to the Customer's account.

25. 25 Flow of Event Example Exceptional flow of events. The Customer can clear a PIN number anytime before committing it and reenter a new PIN number. Exceptional flow of events. If the Customer enters an invalid PIN number, the use case restarts. If this happens three times in a row, the system cancels the entire transaction, preventing the Customer from interacting with the ATM for 60 seconds.

26. 26 Ways to Write Flow of Events You can specify a use case’s flow of events by: Informal structured text (like the example). Formal structured text, with pre- and post- conditions.

27. 27 Use Cases and Scenarios A use case typically has a main flow and a set of exceptional flows. It’s desirable to separate main versus alternative flows. A use case describes a set of scenarios.

28. 28 Use Cases and Collaborations A use case captures the intended behavior of the system. As you implement, you will realize a use case into a collaboration. Analysis of a system should not be influenced by implementation issues.

29. 29 Organizing Use Cases Organizing use cases allows you to have more precise use cases, and make system implementation more approachable. You can organize use cases by specifying generalization, include and extend relationships among them. Organizing your use cases is an important part of creating a simple, balanced, and understandable set of use cases for your system.

30. 30 Organizing Use Cases

31. 31 Modeling Behavior of an Element To model the behavior of an element, Identify the actors that interact with the element. Organize actors by identifying general and more specialized roles. Identify use cases For each use case For each actor, consider the primary ways in which that actor interacts with the element. Consider exceptional ways in which each actor interacts with the element. Organize use cases, applying include and extend relationships to factor common behavior and distinguish exceptional behavior.

32. 32 More Example

33. 33 Hints and Tips A well-structured use case Names a single, identifiable, and reasonably atomic behavior of the system. Is described by a minimal set of scenarios.

34. 34 Hints and Tips When you draw a use case, Show only use cases that are important to understand the behavior of the system. Show only actors that relate to these use cases.

35. 35 Activity Diagrams An activity diagram is essentially a flowchart, showing flow of control from activity to activity. An activity diagram can show concurrency as well. The execution of an activity expands into the execution of individual actions, each of which may change the state of the system or communicate messages.

36. 36 Activity Diagram Example

37. 37 Common Properties Activity diagrams commonly contain Actions Activity nodes Flows Object values Like other diagrams, activity diagrams may contain notes and constraints.

38. 38 Actions An activity may contain several actions. An action is a executable, atomic computations. Executing an action may take small or substantial amount of time.

39. 39 Activity Node An activity node is an organizational unit within an activity. In general, activity nodes are nested grouping of actions or other activity nodes. There are no notational distinction between actions and activity nodes.

40. 40 Control Flows When an action or activity node completes, flow of control passes immediately to the next action or activity node. A flow of control usually starts and ends. In case of an infinite flow, it has no end.

41. 41 Branching You can include branches in an activity diagram.

42. 42 Branching Each outgoing flow of a branch must have a guard. You may use [else] as the default guard. When two paths of control merge back, you may use merge symbol. No guards are necessary on merge. You may achieve an iteration by have actions and branches combined, just like a flowchart.

43. [ มี ] Branching 43 Scan barcode ตรวจสอบว่ามีใน stock หรือไม่ หักสินค้าออกจาก stock ดึงรายการสินค้า ต่อไป [ ไม่มี ]

44. 44 Forking and Joining You may use fork and join to explain concurrency within an activity. Forks and joins should balance.

45. 45 Swimlanes A swimlane specifies a set of actions or activity nodes that share some organizational property.

46. 46 Expansion Regions An expansion region represents an activity model fragment that is performed on the elements of a list or set.

47. 47 Common Uses You typically use activity diagrams in two ways. To model a work flow To model an operation

48. 48 Modeling a Workflow You can use activity diagrams to explain business processes or workflows. To model a workflow, Choose a workflow. Select related business objects. Identify pre-conditions and post-conditions, so you can focus the boundary. Write down simple version of the activity. For complicated actions that appear multiple times, collapse into activity nodes. Consider branching Consider forking and joining. Include important objects as necessary.

49. 49 Example

50. 50 Modeling an Operation