What is a Model? Copyright hebley & Associates

Size: px

Start display at page:

Download "What is a Model? Copyright hebley & Associates"

Tracy Waters
5 years ago
Views:

1 Modeling Overview... as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns - the ones we don't know we don't know. Donald Rumsfeld

2 What is a Model? A model is essentially a picture or representation of something of interest Models are used to illustrate a concept or idea that is typically difficult to describe using the written word Sometimes called a schematic or a blueprint 2

3 Why Model? A model helps us communicate ideas or concepts in a relatively precise and unambiguous way A model supplements the written word when words fail to convey the meaning A Picture is worth a thousand words! 3

4 The IT Model An abstract but formal representation of entities including their properties, relationships and the operations that can be performed on them A visual way of depicting a business, its rules, the use of systems, applications, system architectures, and interactions within the systems 4

are most effective when new concepts or ideas are being evolved Models

5 When to Model? Models can be created at any point in the development life cycle Models are most effective when new concepts or ideas are being evolved Models always precede the implementation of the concepts that they illustrate Pictures before code Pictures after code have little value 5

6 Requirements to Design? Requirements Design 6

7 The Analysis Process Reality Model of Reality Design Code 7

Store Uses 1 address : Address 1 1 name : Text ProductSpecificatio ProductCatalog addsale(...) description : Text.

.. Houses 1 1 1 Describes Sale Register date : Date iscomplete : Boolean SalesLineItem Captures time : Time Contains

..) makenewsale() makepayment(...) makepayment(...) gettotal() 1 Payment Paid-by amount : Money 1.

8 Store Uses 1 address : Address 1 1 name : Text ProductSpecificatio ProductCatalog addsale(...) description : Text... Contains price : Money 1 Looks-in 1 1 itemid : ItemID getspecification(...)... Houses Describes Sale Register date : Date iscomplete : Boolean SalesLineItem Captures time : Time Contains quantity : Integer endsale() becomecomplete() enteritem(...) getsubtotal() makelineitem(...) makenewsale() makepayment(...) makepayment(...) gettotal() 1 Payment Paid-by amount : Money 1... Development Cycle 1 Development Cycle 2 Development Cycle 3 Development Cycle 4 Buy Itemsversion 1 Buy Itemsversion 2 Buy Itemsversion 3 Log In Refund Items 1..* 1..* * Logs-completed * Requirements Cove 8

9 The Analysis Tools What How Use Case Domain Model Activity Diagram State Model Communication Diagram Class Diagram Scope Code 9

10 Model Persistence Models can be transient They exist only as long as it is needed to aid in the communication of ideas or concepts Models may be permanent They exist for as long as the concept that they illustrate They can become part of the system documentation They form a historical record 10

11 The Unified Modeling Language Evolved from the work of Booch, Rumbaugh, Mellor, Yourdon, Harel, Odell et al. Each contributed ideas, concepts, modeling techniques, notations Consortium of partners including HP, IBM, TI, DEC, Microsoft and Rational formalized a standard Came under the governance of the Object Management Group in 1997 as UML 1.0 Current version UML 2.2 published February,

functionality of the system being modeled from the

12 Model Views Logical View Process View Use Case View Physical View Development View The Use Case view describes the functionality of the system being modeled from the perspective of the outside world - typically from the perspective of the users. 12

13 Model Views Logical View Process View Use Case View Physical View Development View The Logical view describes the abstract concepts that comprise the parts of the system. 13

14 Model Views Logical View Process View Use Case View Physical View Development View The Process view describes the process within the system what the system must do to satisfy the use cases. 14

15 Model Views Logical View Process View Use Case View Physical View Development View The Physical view describes how the system s design will be implemented as a set of deployment entities. 15

16 Model Views Logical View Process View Use Case View Physical View Development View The Development view describes how the various parts of the system are organized into modules and components. 16

17 UML 2.0 Diagrams Activity Diagram Class Diagram Communication Diagram Component Diagram Composite Structure Diagram Deployment Diagram Interaction Overview Diagram Object Diagram Package Diagram Sequence Diagram State Machine Diagram Timing Diagram Use Case Diagram Business process, system logical flow Static elements of system classes and relationships Dynamic communication between system elements High level decomposition of system elements Internal structure of classifiers Execution architecture of the system or subsystem Variant of an Activity diagram showing control flow Depicts elements and their relationships at a specific instance in time Groups elements into organizational units Shows the time ordering of element interactions Depicts the states of an element and the transition between states Depicts the change in state or condition of a classifier instance or role over time. Shows Actors and Use Cases and their relationships 17

18 Other Modeling Techniques Data Flow Diagram Illustrates how information flows through a system Flow Chart Form of activity diagram used in procedural code Entity Relationship Diagram Used in database design Robustness Model Validates that use case behavior is reasonable Free-form Diagrams Ad hoc description of almost anything 18

19 Model Formality Models may be drawn formally and precisely using tools such as Rose, Visio or myeclipse Models may also be drawn informally using whiteboards Level of formality will depend on the intent of the model To document for posterity To express transient ideas 19

20 Wealth of Information 20

21 Travel Light You need far less documentation than you think Good documentation should: maximize stakeholder investment fulfill a purpose describe information that is less likely to change describe good things to know be sufficiently accurate, consistent, and detailed be sufficiently indexed 21

22 Don t Rush to Expensive Tools A "plain old whiteboard (POW)" is my favorite modeling tool, and I stand by my claim that whiteboards are the modeling tool with the greatest install base worldwide. Scott Ambler 22

23 Why Document Valid reasons to document include: Your project stakeholders require (and pay for) it The contract requires (and pays for) it To support communication with an external group To think something through Invalid reasons include: Your manager said so! You have some neat development tools There is a section in a PMO template 23

24 No BMUF! Big Modeling Up Front is to be avoided Mistakenly compare software development to civil engineering Software cannot be fully specified before construction Not all models have value Typically only the well understood components can be modeled 24

25 Just Good Enough! Value Ideal Realistic From Scott Ambler Effort 25

26 Summary Models aid in understanding a concept Models aid in communicating a need Artifacts may be models as well as formal documents Models may be permanent or temporary Don t waste time on models that have little value 26

From designing to coding

From designing to coding l st step: sensibly split work among team members Choose splits along thin interfaces l Probably not equal parts; split biggest parts again later Formalize the interfaces think