Activity Diagram Berbasis Object Oriented
Download as PPT, PDF0 likes13 views
The document discusses the goals and methodologies of object-oriented (OO) design, emphasizing the importance of activity diagrams and state charts for modeling systems. It highlights the development of class diagrams and their details, as well as techniques for visualizing and modeling complex processes, including parallel actions and data flows. Additionally, it covers when to create activity diagrams and state charts for various applications, including data processing and device management.
![What does the Rake
symbol mean?
When to use it?
Receive Video
Order
Fill Order Send Invoice
Deliver
Order
Receive Payment
Close Order
Accept a signal
Resend Invoice
Cancel
request
Cancel Order
30 days since sent last invoice,
and no payment received
A time signal
Fig. 28.5
Deliver Regular Deliver Rush
[ rush ]
[ else ]
Deliver Order
Decision: Any
branch happens.
Mutual exclusion
Merge: Any input leads
to continuation. This is
in contrast to a join, in
which case all the
inputs have to arrive
before it continues.
Figure 28.6](https://image.slidesharecdn.com/17activity-state-diagrams-250106010848-fee440ac/85/Activity-Diagram-Berbasis-Object-Oriented-6-320.jpg)
![State charts in UML:
States in ovals, Transitions as arrows
ïź Transitions labels have three
optional parts:
Event [Guard] / Action
ï± Find one of each
ï± Item Received is an event,
/get first item is an action,
[Not all items checked] is a
guard
ïź State may also label activities,
e.g., do/check item
ï± Actions, associated with
transitions, occur quickly
and arenât interruptible
ï± Activities, associated with
states, can take longer and
are interruptible
ï± Definition of âquicklyâ depends
on the kind of system,
e.g., real-time vs. info system](https://image.slidesharecdn.com/17activity-state-diagrams-250106010848-fee440ac/85/Activity-Diagram-Berbasis-Object-Oriented-8-320.jpg)
![Classes as active state machines
ïź Consider whether a class should keep track of its own internal state
ï± Example from Bertrand Meyer: first cut design of LINKED_LIST class
class LINKABLE[T] linkable cells
ââ
feature
value:T;
right: LINKABLE[T]; next cell
ââ
ââroutines to change_value, change_right
end;
class LINKEDLIST[T]
feature
nb_elements: INTEGER;
first_element: LINKABLE[T];
value(i:INTEGER):T is value of i th element; loop until it reaches the ith element
ââ â
insert(i:INTEGER; val:T); loop until it reaches ith element, then insert val
ââ
delete(i:INTEGER); loop until it reaches ith element, then delete it
ââ
ïź Problems with first cut?
â
ïź Getting the loops right is tricky (loops are error prone)
â
ïź Redundancy: the same loop logic recurs in all these routines
ï± Reuse leads to inefficiency: suppose I want a routine search
ï± Find an element then replace it: I'll do the loop twice!
ï± Need some way to keep track of the position I found!
ï± Could return the LINKABLE cell found, but this would ruin encapsulation](https://image.slidesharecdn.com/17activity-state-diagrams-250106010848-fee440ac/85/Activity-Diagram-Berbasis-Object-Oriented-13-320.jpg)
Activity Diagram Berbasis Object Oriented
- 1. Activity Diagrams and State Charts for detailed modeling Larman, chapters 28 and 29 CSE 432: Object-Oriented Software Engineering Glenn D. Blank
- 2. Goals of OO design ïź OO design develops the analysis into a blueprint of a solution ï± Where does the âblueprintâ metaphor come from? ïź OO design starts by fleshing the class diagrams ï± Coad & Nicola call this "the continuum of representation principle: use a single underlying representation, from problem domain to OOA to OOD to OOP," i.e., class diagrams ï± Reworks and adds detail to class diagrams, e.g., attribute types, visibility (public/private), additional constraints ï± Looks for opportunities for reuse ï± Addresses performance issues, both for system and users ï± Designs UI, database, networking, as needed ï± Designs ADT to describe the semantics of classes in more detail ï± Develops unit test plans based on class diagrams and ADT design
- 3. Activity Diagram - Figure 28.1 Receive Video Order Fill Order Send Invoice Deliver Order Receive Payment Close Order Fulfillment Customer Service Finance Order Invoice start Action. It does something. There is an automatic transition on its completion. A transition supports modeling of control flow. Fork. One incoming transition, and multiple outgoing parallel transitions and/or object flows. Partitions. Show different parties involved in the process Join. Multiple incoming transitions and/or object flows; one outgoing transition. The outgoing continuation does not happen until all the inputs arrive from all flows. Object Node. An object produced or used by actions. This allows us to model data flows or object flows. end of activity âą Petri nets notation âą What are actions? Transitions? âą How does it support parallelism?
- 4. When to create Activity diagrams? ïź Modeling simple processes or complex ones? ïź Modeling business processes ï± Helps visualize multiple parties and parallel actions ïź Modeling data flow (alternative to DVD notation) ï± Visualize major steps & data in software processes 1 Check Course Availability Courses 2 Check Applicant Qualification Applications Students Applicant application course data application application student data accept/deny reply external actor data store, such as a DB, DB table, or file data flow process DFD for Automated Course Registration System
- 5. Activity diagram to show data flow model Notation pros & cons? Student Registration System Application Complete Application Check Course Availability «datastore» Courses «datastore» Applications Check Applicant Qualification «datastore» Students Accept/Deny Reply 1 Check Course Availability Courses 2 Check Applicant Qualification Applications Students Applicant application course data application application student data accept/deny reply external actor data store, such as a DB, DB table, or file data flow process DFD for Automated Course Registration System Figure 28.3 Figure 28.2
- 6. What does the Rake symbol mean? When to use it? Receive Video Order Fill Order Send Invoice Deliver Order Receive Payment Close Order Accept a signal Resend Invoice Cancel request Cancel Order 30 days since sent last invoice, and no payment received A time signal Fig. 28.5 Deliver Regular Deliver Rush [ rush ] [ else ] Deliver Order Decision: Any branch happens. Mutual exclusion Merge: Any input leads to continuation. This is in contrast to a join, in which case all the inputs have to arrive before it continues. Figure 28.6
- 7. State chart Diagrams initial State state transition event A State chart diagram shows the lifecycle of an object âą A state is a condition of an object for a particular time âą An event causes a transition from one state to another state âą Here is a State chart for a Phone Line object:
- 8. State charts in UML: States in ovals, Transitions as arrows ïź Transitions labels have three optional parts: Event [Guard] / Action ï± Find one of each ï± Item Received is an event, /get first item is an action, [Not all items checked] is a guard ïź State may also label activities, e.g., do/check item ï± Actions, associated with transitions, occur quickly and arenât interruptible ï± Activities, associated with states, can take longer and are interruptible ï± Definition of âquicklyâ depends on the kind of system, e.g., real-time vs. info system
- 9. When to develop a state chart? Model objects that have change state in interesting ways: ïź Devices (microwave oven, Ipod) ïź Complex user interfaces (e.g., menus) ïź Transactions (databases, banks, etc.) ïź Stateful sessions (server-side objects) ïź Controllers for other objects ïź Role mutators (what role is an object playing?) ïź Etc.
- 10. Case Study: Full Screen Entry Systems â ïź Straightforward data processing application: menu driven data entry (see overhead) â ï± Each menu comes with a panel of information & lets user choose next action ï± Interaction during a airline reservation session ï± Enquiry on flights, information & possible new states ïź Meyer shows different ways to solve problem ï± goto flow (50's), ï± functional decomposition (70's) ï± OO design (90's): improves reusability and extensibility
- 11. Superstates (nested states) ïź Example shows a super-state of three states ïź Can draw a single transition to and from a super-state ïź How does this notation make things a bit clearer?
- 12. Concurrency in state diagrams ï± Dashed line indicates that an order is in two different states, e.g. Checking & Authorizing ï± When order leaves concurrent states, itâs in a single state: Canceled, Delivered or Rejected
- 13. Classes as active state machines ïź Consider whether a class should keep track of its own internal state ï± Example from Bertrand Meyer: first cut design of LINKED_LIST class class LINKABLE[T] linkable cells ââ feature value:T; right: LINKABLE[T]; next cell ââ ââroutines to change_value, change_right end; class LINKEDLIST[T] feature nb_elements: INTEGER; first_element: LINKABLE[T]; value(i:INTEGER):T is value of i th element; loop until it reaches the ith element ââ â insert(i:INTEGER; val:T); loop until it reaches ith element, then insert val ââ delete(i:INTEGER); loop until it reaches ith element, then delete it ââ ïź Problems with first cut? â ïź Getting the loops right is tricky (loops are error prone) â ïź Redundancy: the same loop logic recurs in all these routines ï± Reuse leads to inefficiency: suppose I want a routine search ï± Find an element then replace it: I'll do the loop twice! ï± Need some way to keep track of the position I found! ï± Could return the LINKABLE cell found, but this would ruin encapsulation
- 14. Classes as active state machines (cont.) ïź Instead, view LINKED_LIST as a machine with an internal state ï± Internal state is information stored as attributes of an object ïź What have we added to represent internal state? ï± Cursor: current position in the list ï± search(item) routine moves the cursor until it finds item ï± insert and delete operate on the element pointed at by cursor ï± How does this simplify the code of insert, delete, etc.? ï± Client has a new view of LINKED_LIST objects: ï± l.search(item); find item in l ââ ï± if not offright then delete end; delete LINKABLE at cursor ââ ï± Other routines move cursor: l.back; l.forth
- 15. Key idea for OOD: data structures can be active ï± Active structures have internal states, which change ï± Routines manipulate the object's state ïź What other classes could be designed this way? ï± Files, random number generators, tokenizers, ... ï± Class as state machine view may not be obvious during analysis ï± A good reason for redesign!