Activity & Class Modeling Labs Discussion p3 T120B029 200 4 pavasario sem.

1. Activity & Class Modeling Labs Discussion p3T120B0292004 pavasario sem.

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

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. 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. 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. 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. Activity Diagram • 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. Activity Diagram (Example) Explicit branch condition (that appears on exit from activity state) Multiple exit transitions (branch condition that is internal to activity state) T120B029

9. Class Models and Class Discovery T120B029

10. 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

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

12. 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

13. Package Diagram (BCED) T120B029

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. In Class Exercise Continued Class Discovery T120B029

30. 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

31. Next Session • More Fun with UML • State Charts • Sequence Diagrams T120B029