Presentation is loading. Please wait.

Presentation is loading. Please wait.

Activity & Class Modeling Labs Discussion p3 T120B029 2012 pavasario sem.

Similar presentations


Presentation on theme: "Activity & Class Modeling Labs Discussion p3 T120B029 2012 pavasario sem."— Presentation transcript:

1 Activity & Class Modeling Labs Discussion p3 T120B029 2012 pavasario sem.

2 2 Discussion Question Explain the role and place of an activity diagram in system modeling T120B029

3 3 Activity Modeling Serves as a transition between the use case and the interaction model. Use cases are a necessary pre- condition Use Cases – Actor or User Perspective Activity Diagram – System Perspective T120B029

4 4 Activity Modeling Activity models show a flow of logic and varying levels of detail necessary to complete computations While activity models define the flow of activities, they do not show objects T120B029

5 5 How Activity Models Work An event from an actor triggers a use case This begins the execution of the activity The activity proceeds through state transitions The activity completes T120B029

6 6 Activity Diagrams An Activity State is shown as a rounded rectangle. To determine activities, look at the use case documentation. For each use case, determine the system response. E.G. Customer chooses purchase function => GetPurchaseDetails() T120B029

7 7 Activity Diagrams The activity diagram shows transitions between activities Unless you are writing an infinite loop (e.g. Multi-media kiosk) you need an initial and final state. –Initial State – Filled Circle –Final State – Bullseye Branches in the program logic are shown as a diamond Concurrent Processing is a bar line T120B029

8 8 Activity Diagrams An activity diagram shows flow control within a system An activity diagram is a special case of a state chart diagram in which states are activities (“functions”) Two types of states: –Action state: Cannot be decomposed any further Happens “instantaneously” with respect to the level of abstraction used in the model –Activity state: Can be decomposed further The activity is modeled by another activity diagram T120B029

9 9 Activity Diagram: Modeling Decisions T120B029

10 10 Activity Diagrams: Modeling Concurrency Synchronization of multiple activities Splitting the flow of control into multiple threads Synchronization Splitting Archive Incident Open Incident Document Incident Allocate Resources Coordinate Resources T120B029

11 11 Activity Diagrams: Swimlanes Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions. Archive Incident Dispatcher FieldOfficer Open Incident Document Incident Allocate Resources Coordinate Resources T120B029

12 12 Activities (example 2) The system assigns a unique order number and a customer account number to the purchase order and it stores the order information in the database.

13 13 Activity Diagram(example 2) Multiple exit transitions (branch condition that is internal to activity state) Explicit branch condition (that appears on exit from activity state)

14 Class Models and Class Discovery T120B029

15 15 The Snowflake Rule The Snowflake Rule – For a non- trivial system, no two analysts will come up with the identical class models for the same application domain T120B029

16 16 Class Models Define the internal state of the system Elements –Classes –Attributes –Operations –Association (Generalization, Aggregation, Composition) Classes Define Business Objects T120B029

17 17 Class Models (Continued) Types of Classes (BCED Approach) –Entity Classes – Database Model & Permanent Objects –Boundary Classes – GUI –Control Classes – Control program logic –Database Access Classes Methodology for Constructing Classes is same as use cases – Use a table and derive candidate classes T120B029

18 18 Package Diagram (BCED) T120B029

19 19 Determining Classes Four Questions –Is this concept a container for data? –Does it have separate attributes that will take on different values? –Would it have many instance objects? –Is it in the scope of the application domain? Remember, this is an iterative task! T120B029

20 20 Specifying Classes After we have identified our initial set of classes, we will want to specify them Here, we will begin drawing a class diagram and defining class properties CASE tools are of great assistance here T120B029

21 21 How do we name classes? Names should begin with a capital letter, e.g. Reservation In compound words, the first letter of each word should be capitalized, e.g. OnTimeArrival The name should be a singular noun The name should be meaningful in a business context The name should not be longer than 30 characters T120B029

22 22 Discovering Class Attributes Recall that there are three parts to the class icon in UML (name, attributes, and operations) While discovering classes, it is helpful to discover attributes at the same time The first step for determining attributes is to identify those attributes that help us to understand the states of the object T120B029

23 23 How do we name attributes? Use all lower case letters, e.g. time Words in a compound name should be separated by an underscore, e.g. ticket_number It would also be helpful to keep them under 30 letters It should also be meaningful in a business context as opposed to a pure tech approach T120B029

24 24 Class Attributes Class structure is defined by attributes Defining attributes is an art, not a science, but there are some techniques we will explore later T120B029

25 25 Class Attributes Customer customer_name : String customer_address : String phone_number : String email_address : String (from Use Case View) Order order_number : String order_date : Date ship_address : String order_total : Currency order_status : String salesperson_name : String T120B029

26 26 Modeling Associations Recall that associations connect objects in the system Associations are the most essential kind of relationships in the model Associations support the execution of use cases (i.e. They tie together the state and behavior models) T120B029

27 27 Discovering Associations Finding associations should be a side effect of class discovery An association is a class attribute with a non primitive data type Associations permit object collaboration Remember that associations should be binary at most. We need to replace any ternary associations or those with greater extents with a cycle of binary associations T120B029

28 28 Rules for Specifying Associations In order to specify associations, we need to: –Name them –Name the association roles –Determine the association multiplicity When we name associations, we should name them in the same way as attributes We also need to designate the role names. When we use case tools, these will become attributes within the appropriate classes It is also good to specify the multiplicities T120B029

29 29 Modeling Aggregation and Composition Aggregation and composition are forms of association Aggregation and generalization are the two most powerful techniques for re-use in UML T120B029

30 30 Discovering Aggregations and Compositions The “litmus test” for discovering aggregation and composition is reading the relationship with the words “has” and “is part of” Examples: –“A book has chapters” –“A student is part of a class” If it does not make sense in a natural language, then it should not make be an aggregation or composition T120B029

31 31 More about aggregation and composition Remember that composition (by value) is stronger than aggregation (by reference) Use a solid diamond for composition and a hollow diamond for aggregation T120B029

32 32 Modeling Generalizations and Relationships Recall that generalization is a relationship between a generic class and its sub-classes Generalization supports inheritance in object oriented environments It also allows for substitution and polymorphism (same operation meaning different things) Polymorphism works best when used with inheritance T120B029

33 33 Discovering Generalizations We attempt to discover in parallel with class determination The litmus test for generalization are the phrases: –“can be” –“is a kind of” E.g. a pilot is a kind of employee In UML, we specify generalizations using a solid line with an arrowhead pointing to the superclass T120B029

34 In Class Exercise Continued Class Discovery T120B029

35 35 Home Exercise Assume that the system you reviewed during the first half of the lecture will have an object oriented implementation Discover a set of candidate classes, attributes, and relationships amongst these classes Write all names on the paper and turn it in (This is your participation for the week) T120B029

36 36 Next Session More Fun with UML –State Charts –Sequence Diagrams T120B029


Download ppt "Activity & Class Modeling Labs Discussion p3 T120B029 2012 pavasario sem."

Similar presentations


Ads by Google