Activity & Class Activity & Class ModelingModeling

Labs DiscussionLabs Discussionp3p3

T120B029T120B02920020044 pavasario sem. 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)

Display Current Configuration

Get Order Request

Display Purchase Form

Get Purchase Details

Store Order

Email Order Details

[ timeout ]

[ incomplete ]

[ OK ]

Multiple exit transitions (branch condition that is internal to activity state)

Explicit branch condition (that appears on exit from activity state)

T120B029

Class Models and Class Models and Class DiscoveryClass Discovery

Class Models and Class Models and Class DiscoveryClass 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)

Boundary Package

Control Package

Entity Package

Database Package

Boundary Package

Control Package

Entity Package

Database Package

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

Class Attributes

Customer

customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String

(from Use Case View)

Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String

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

In Class Exercise In Class Exercise ContinuedContinued

In Class Exercise In Class Exercise ContinuedContinued

Class DiscoveryClass 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