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

Slides:



Advertisements
Similar presentations
Alternative Approach to Systems Analysis Structured analysis
Advertisements

© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 9 Slide 1 Appendix 3 Object-Oriented Analysis and Design.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall A.1.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Object-Oriented Analysis and Design
Department of Computing
Copyright W. Howden1 Lecture 11: UML Terminology and Additional Models and Notation.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
1 Lecture 2: Elaboration Tasks and Domain Modeling.
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix.
Lecture a: Additional UML Models: Package, Activity, Deployment Lecture b: Generalization, Aggregation and Additional Domain Model Notation Copyright W.
Modelling classes Drawing a Class Diagram. Class diagram First pick the classes –Choose relevant nouns, which have attributes and operations. Find the.
SE-565 Software System Requirements More UML Diagrams.
Unified Modeling Language
Chapter 7 Structuring System Process Requirements
Object-Oriented Systems Analysis and Design Using UML
Lecture 6 Unified Modeling Language (UML)
Chapter 7 Structuring System Process Requirements
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 8 Slide 1 Chapter 9 Structuring System Data Requirements.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 21. Review ANALYSIS PHASE (OBJECT ORIENTED DESIGN) Functional Modeling – Use case Diagram Description.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Lab 04.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
CHAPTER 13: OBJECT-ORIENTED DATA MODELING (OVERVIEW) © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
Activity & Class Modeling Labs Discussion p3 T120B pavasario sem.
Sept. 18, 2003CS WPI1 CS 509 Design of Software Systems Lecture #3 Thursday, Sept. 18, 2003.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
What is a Structural Model?
Design Jon Walker. More UML ● What is UML again?
Design Model Lecture p6 T120B pavasario sem.
 Week08.  Review Schedule Weeks 8-14  This week o Review last class o Introduce Class Diagrams o ICE-03 Sheridan SYST Engineering Quality Systems.
Introduction to UML CS A470. What is UML? Unified Modeling Language –OMG Standard, Object Management Group –Based on work from Booch, Rumbaugh, Jacobson.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
Chapter 3: Introducing the UML
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
DOMAIN CLASSES – PART 1 BTS430 Systems Analysis and Design using UML.
Business Process and Functional Modeling
Chapter 3 DOCUMENTING ACCOUNTING SYSTEMS
Appendix 3 Object-Oriented Analysis and Design
CHAPTER
UML Diagrams: Class Diagrams The Static Analysis Model
Object-Oriented Modeling
Jim Fawcett CSE681 – Software Modeling and Analysis Fall 2017
Business System Development
DATA REQIREMENT ANALYSIS
Roberta Roth, Alan Dennis, and Barbara Haley Wixom
The Movement To Objects
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Object-Oriented Analysis and Design
Entity-Relationship Model
Activity and State Transition Diagram
The Process of Object Modeling
Business System Development
Advanced Java Programming
Lec 3: Object-Oriented Data Modeling
Week 12: Activity & Sequence Diagrams
Chapter 20 Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
SYS466 Domain Classes – Part 1.
Business Analysis More on Classes Chris Russell O2.41
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Appendix A Object-Oriented Analysis and Design
Appendix A Object-Oriented Analysis and Design
Appendix 3 Object-Oriented Analysis and Design
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

Activity & Class Modeling Labs Discussion p3 T120B 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 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 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 Activity Diagram: Modeling Decisions T120B029

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 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 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 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)

Class Models and Class Discovery T120B029

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 Class Models Define the internal state of the system Elements –Classes –Attributes –Operations –Association (Generalization, Aggregation, Composition) Classes Define Business Objects T120B029

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 Package Diagram (BCED) T120B029

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 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 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 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 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 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 Class Attributes Customer customer_name : String customer_address : String phone_number : String _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 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 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 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 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 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 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 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 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 Continued Class Discovery T120B029

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 Next Session More Fun with UML –State Charts –Sequence Diagrams T120B029