Business Analysis ITEC-630 Fall 2009

1. Business AnalysisITEC-630 Fall 2009 Additional UML and Non-UML Diagrams Professor J. Alberto Espinosa

2. Objectives • Develop familiarity with some UML modeling diagrams • Develop familiarity with important non-UML modeling diagrams • Using MS Visio for modeling

3. Important UML Diagrams

4. Important UML Diagram Models • Use Case Diagrams (done) • Packages – organizing the Use Cases (& other models) • Activity Diagrams • Diagrams that explain Use Case workflows (sometimes useful, but use case text is often preferred) • Some times also used to diagram dependencies between Use Cases • And for business process models • Class Diagrams – describe the types of objects in a system and the static relationships among them

5. The Use Case Modeling Process Develop Base Use Case Descriptions Done Elaborated Use Case Descriptions Done Model Extend, Include & Generaliz Done Map Use Cases to Object Models DevelopInstance Scenarios Next Prepare for Use Case Modeling Initial Use Case Modeling Expand Use Case Model Test Use Cases & Doc Organize the Use Cases Ongoing Use Case Management

6. Packages

7. Packages • Packages are a key aspect of UML • A package contains a group or related Use Cases or model • They are most useful to organize Use Cases and other models when the get too large or complex to represent in a simple diagram • A package diagram is one that shows “packages” of artifacts (e.g., Use Cases, Class Diagrams, etc.) and their respective dependencies • A dependency between any two entities exist when events, actions or definitions in one entity influence events, actions or definitions in the other entity

8. How to Group Use Cases into Packages • It is better to group Use Cases by business functionality (e.g., account management, ATM operation) than by sub-system • A system architect may later combine several Use Case packages into 1 sub-system, or split a package into more than 1 sub-system • It helps document the scope of each business function supported by the system • Focus on what makes the most sense for primary actors • Two important principles to keep in mind: • Maximize cohesion (i.e., business function similarity) within packages • Minimize coupling (i.e., dependencies) between packages

9. Example: Loan Processing Application Packages

10. Example:A Package Diagram for ATM System

11. Example: AOL Student ProjectCity Search ApplicationVisio\UseCase_AOL.vsd Functional Division of Responsibilities • Team 1: Data Acquisition and Management Functions • Team 2: AOL User Front End

12. Example: AOL ProjectTeam 1 Package – Data Acquisition

13. Example: AOL ProjectTeam 2 Package – Front End

14. Activity Diagrams

15. Activity Diagrams • General: they describe sequencing of activities • Particularly useful to visualize business workflows and processes • Sometimes used with Use Cases: • To diagram the flow of events within a Use Case • To model dependencies between Use Cases • Activity diagrams are also used for other models, such as: • Business process models • Test cases

16. Example:WithdrawFundsUse Case

17. Example:WithdrawFundsActivityDiagram

19. Class Diagrams(Static Structure)

20. Object-Oriented Analysis • OO is most prevalent software system development paradigm today • There are OO analysis, design and programming methods • These are different, but related concepts and methods • OO analysis aims to discover and describe objects (their properties/attributes and behaviors/methods) in the system domain – what they are, their attributes, their behaviors (i.e., methods), how they collaborate with and relate to each other, etc.

21. Objects and Classes • An object is a person, place, event or other thing • A class is a category or grouping of similar objects(e.g., professors) • We say that an object is an “instance” of a class (e.g., A. Espinosa) • An object has attributes (i.e., data) andmethods (or operations) (i.e., programs) • Objects inherit attributes and methods from their class • Classes inherit attributes and methods from super-classes

22. Methods or Operations • Methods or Operations are procedures/programs (written in an OO programming language) to update, manipulate or query data in object attributes • They are functions or services available to all objects of the class in which the methods are defined – 4 main types: • Constructor – creates a new object in the class (equivalent to Insert SQL query or C in CRUD matrix) • Query – accesses data in an object’s attributes, no side effects (equivalent to Select SQL query or R in CRUD matrix) • Update – alters the content of an object, with side effects (equivalent to Update SQL query or U in CRUD matrix) • Scope – applies to the whole class or a range of objects rather than a single object

23. Inheritance • Objects inheritoperations and properties from their respective class • Classes can be created under other classes • Sub-classes inherit operations and properties from super-classes • Thus, OO models have an “inheritance structure” • Gen-Spec or Generalization (“is a”) • Whole-Part or Aggregation (“is part of”)

24. Inheritance Types and Structure:Gen-Spec (Is a) and Whole-Part (Is part of) Properties Multiplicities (similar to cardinality): Not Needed Needed Methods orOperations Class Inheritance Sub-Class Generalization-Specialization (Is a) Aggregation or Whole-Part (Is part of) Two Types of Inheritance

25. Object-Oriented Databases

26. Object Oriented (OO) Database Modeling • OO Database Models or Class Diagrams are like ERDs • An object is like an instance of an entity or a record (i.e., row) in a database table • A class is like an entity in an ERD or a table in the database • Attributes are called properties • But they also include operations (or methods) and inheritance

27. Terminology Equivalence

28. Example: Course Registration OO Database Model Classes (like entities in ERD’s) Relationships (like ERD’s) w/multiplicities (like cardinality) + Operations or Methods + Inheritance In sum, OO database models are like class diagrams, but also include relationships like in data models (or ERD’s)

29. Example: ATM OO Database Model Multiplicity (UML term) = Cardinality (database term)How many instances of one class can be associated with another class 0..1 (0 or 1); 1 (only 1), 0..* (0 or many), * (many, but not 0)

30. Popular non-UML Diagrams

31. Non-UML System Modeling Methods Process-Oriented Methods (process-driven systems): • Flowcharts • Data Flow Diagrams (DFD) • Structure Charts Data-Oriented Methods (data-driven systems): • Data Modeling: Entity Relationship Diagrams (ERD) • Data Dictionaries Control-Oriented Methods (real-time systems): • State Transition Diagrams (STD)

32. Process Diagrams:Dataflow Diagrams

33. No. label label label Data Flow Diagrams (DFD) Process oriented modeling method that shows how the data moves through a system • Most suitable for process oriented systems • Good visual representation of a system • Simple: only uses only 4 symbols label Data Source/Sink (external) Data Store Data Flow Process [Gane-Sarson Symbols]

34. Data Flow Diagram Levels DFDs start at a high level of abstraction and proceed to more detailed levels: • Context Diagram • Level-0 Diagram • Level-1, 2, … n Diagrams • Primitive DFD

35. Context Diagram • Highest level view of the system • Contains ONLY one process, i.e., the “system” • It also shows all external data sources/sinks • (“electronic” or “manual”) • And all data flows between data sources/sinks and the process • It contains NO data stores

36. DFD Context Diagram Example Food Ordering System

37. Level-0 Diagram • Expands the main process from context diagram • Represents the system’s major processes • Which are the primary individual processes at the highest possible level • This is called “functional decomposition”

38. Level-0 DiagramFood Ordering System

39. Level-1 Diagram for Process P1Food Ordering System

40. Primitive DFD • Lowest level DFD • When further decomposing no longer necessary • What next? • Describe the primitive in structured English • Or using pseudo-code • Turn over to programmers to start coding modules