1. Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, 2009. Hans Van Vliet, Software Engineering: Principles and Practice, third edition, John Wiley & Sons, 2008.

2. What Is a Model? Pairs (2 minutes) 2

3. Models ‘Complete’ meaning no additional information is needed to understand the system from that perspective abstraction of some entity –understand before build –omits nonessential details examples: –architectural models to show customers –airplane scale models –storyboards of advertisements –outlines of books 3

4. Why Build a Model? Purposes of a model –Testing a real entity before building it –Communication with customers –Visualization –Reduction of complexity 4

5. What Types and How Many? No consensus but multiple models of different types, e.g., 4+1 view model of S/W architecture 1 5 Logical view Development view Physical view Process view Scenarios 1 P. Kruchten. The 4+1 view model of architecture, IEEE Software, 12(6):42-50, November 1995.

6. 4+1 View Model Use case view –functionality of system from outside perspective, e.g., in UML use case diagram Logical view –description of system's parts, e.g., in UML class, object, state machine, and interaction diagrams Process view –description of process within system, e.g., in UML activity diagram Development view –organization of system's part into modules and components, e.g., in UML package and component diagrams Physical view –system's parts into real-world entities, e.g., in UML deployment diagram 6

7. Different Models Several models will be considered in developing our system Use case model: describes requirements from the user perspective Design model: describes classes and objects Implementation model: source code Test model: test cases and test procedures 7

8. Investigate: People and machines playing some role (actors) Items produced, consumed, or modified Functions performed Modes of operation that determine when functions are performed 8

9. Analysis All aspects of the problem domain need to be investigated. Decompose the problem into smaller problems until the entire problem is fully understood. The models that depict information, function, and behavior must be constructed in a manner that uncovers detail. 9

10. Note: "Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful."; "Essentially, all models are wrong, but some are useful." –George E.P. Box & Norman R. Draper, Empirical Model-Building and Response Surfaces (Wiley 1987) pp. 74 and 424. (Professor of statistics, U of Wisconsin) 10

11. Operational Principles: Analysis Methods The information domain of a problem must be represented and understood. The functions that the software is to perform must be defined. The behavior of the software (as a consequence of external events) must be represented. 11

12. Modeling Views It all comes down to these: Objects: data Functions: transformations of data States: transitions controlling transformations 12

13. Data (Static) Models Used to understand the data and actors in a system Abstraction of the information needed and generated by the system Describes the problem domain Helps identify, classify, and abstract the problem 13

14. Function (Transformational) Models Used to understand the transformations that take place in the system Used to understand the inputs and outputs for computations 14

15. State (Dynamic) Models Used to understand states and modes of the system Used to specify the flow of control through the system and system components 15

16. Modeling Data Dictionary Object Model - static, structural, data aspects of system Dynamic Model - temporal, behavioral, “control” aspects of system Functional Model – transformational, “function” aspects of system E-R Diagram Class Diagram State-Transition Diagram Decision Tables Collaboration Diagram Data-flow Diagram 16

17. Static Models Entity Relationship Models Class Models 17

18. Dynamic Models Event trace –Show a sequence of events and associated responses Message sequence chart –Enhanced event trace notation –Vertical lines are entity time lines (time flows from top to bottom) –Horizontal lines are messages or events 18

19. Dynamic Models (Cont.) State Machines –Should remind you of FSMs from theory. –Nodes are states –Arcs are transitions Event (condition)/action Instantaneous Statecharts: UML state machine notation 19

20. Functional Models Data Flow Diagrams –Processes –Data –Data store Use Cases 20

21. Static Models Pairs (10 minutes) –Read about ER diagrams PP 263-265 What are the nodes (node types)? What are the edges? 21

22. In Class: Diagram the Following A library has books and journals, and each can be checked out. A patron has a name, a UTEP ID number, an address. A patron can check out any number of books or journals. When a book or journal is checked out, it must be returned in 5 days (so we must keep track of the checkout date) 22

23. In Class: Static Models Show how you can use an ER diagram to represent –Association –Aggregation –Generalization –Composition –role names –multiplicities 23