1
play

1 What is a good model? Models of models of models Intuitively: A - PDF document

Sep 22, 2022 •216 likes •389 views

What is modeling? Chair of Softw are Engineering Building an abstraction of reality Software Engineering Abstractions from things, people, and processes Spring Semester 2008 Relationships between these abstractions Abstractions are

  1. What is modeling? Chair of Softw are Engineering Building an abstraction of reality Software Engineering � Abstractions from things, people, and processes Spring Semester 2008 � Relationships between these abstractions Abstractions are simplifications � They ignore irrelevant details Slides: Based on KSE06 – With kind permission of Peter M ü ller � They represent only the relevant details � What is relevant or irrelevant depends on the purpose of Lecture 16+ 17: Modeling with UML the model Draw complicated conclusions in the reality with simple steps in the model Software Engineering, lecture 16+ 17: Modeling in UML 2 Example 1: cat Example 2: street map Software Engineering, lecture 16+ 17: Modeling in UML 3 Software Engineering, lecture 16+ 17: Modeling in UML 4 Example 3: atom models in physics Why model software? Bohr model Software is getting increasingly more complex � Nucleus surrounded by � Windows 2000: ~40 millions lines of code electrons in orbit � A single programmer cannot manage this amount of code � Explains, e.g., spectra in its entirety Quantum physics Code is not easily understandable by developers who did not write it � Position of electrons described by probability distribution � Takes into account We need simpler representations for complex systems Heisenberg’s uncertainty principle Modeling is a means for dealing with complexity Software Engineering, lecture 16+ 17: Modeling in UML 5 Software Engineering, lecture 16+ 17: Modeling in UML 6 1

  2. What is a good model? Models of models of models … Intuitively: A model is good if relationships, which are valid in Software development is transformation of models reality R, are also valid in model M f M2 M 2 M 2 Definition Interpretation I: R → M I 2 : System Design Subsystem f M1 Decomposition M 1 M M I: Mapping of real things in reality R M 1 f M to abstractions in model M I 1 : Analysis Object f M : Relationship between I I Model f M abstractions in M M M f R : Relationship between real things f R I: Requirements Elicitation in R Functional R R Model f R R R In a good model this diagram is commutative Software Engineering, lecture 16+ 17: Modeling in UML 7 Software Engineering, lecture 16+ 17: Modeling in UML 8 Modeling the Real World Modeling example: data modeling Abstraction Abstraction Tuple of � Continents � Address Bank client � Countries � Asset class Problem domain � Oceans Modeling � At least one � Their positions account g Method Address n l i Client e d � … Asset class o d M o h t e Representation M 1 Model of model n Balance of problem Account possesses Account No. ER-Diagram Software Engineering, lecture 16+ 17: Modeling in UML 9 Software Engineering, lecture 16+ 17: Modeling in UML 10 Modeling example: object modeling The Unified Modeling Language, UML UML is a modeling language � Using text and graphical notation Abstraction � For documenting specification, Object with analysis, design, and implementation Bank client � Data Importance � Operations � Recommended OMG (Object Management Group) Modeling standard notation Method � De facto standard in industrial software development 1 1 1 1..* Address Client Account Balance Asset class Alternative: Business Object Notation (BON) Account No. � Mainly used in the Eiffel community UML Class Diagram Software Engineering, lecture 16+ 17: Modeling in UML 11 Software Engineering, lecture 16+ 17: Modeling in UML 12 2

  3. Bit of history UML notations In 1994-95 Rational Software Corporation Use case diagrams – requirements of a system hires the Three Amigos : Class diagrams – structure of a system � Jim Rumbaugh (OMT) Interaction diagrams – message passing � Grady Booch (Booch method) � Sequence diagrams � Ivar Jacobson (OOSE method) � Collaboration diagrams In 1996 Rational decides to unify different methods and an State and activity diagrams – actions of an object international consortium is organized Implementation diagrams In 1997 first version gets standardized (UML 1.0) � Component model – dependencies between code Many minor revisions to fix bugs and fill gaps in semantics � UML mostly criticized for lack of semantics � Deployment model – structure of the runtime system In 2004 UML 2.0 gets standardized � Attempt to define precise semantics Object constraint language (OCL) � Current standard Software Engineering, lecture 16+ 17: Modeling in UML 13 Software Engineering, lecture 16+ 17: Modeling in UML 14 UML notations System models Use case diagrams – requirements of a system 1. What are the transformations? → Functional Model Class diagrams – structure of a system � Create scenarios and use case diagrams Interaction diagrams – message passing � Talk to client, observe, get historical records → Object Model � Sequence diagrams 2. What is the structure of the system? � Collaboration diagrams � Create class diagrams State and activity diagrams – actions of an object � Identify objects, associations and their multiplicity, attributes, operations Implementation diagrams 3. What is its behavior? → Dynamic Model � Component model – dependencies between code � Create sequence diagrams � Deployment model – structure of the runtime system � Show senders, receivers, and sequence of events � Create state diagrams (for the interesting objects) Object constraint language (OCL) Software Engineering, lecture 16+ 17: Modeling in UML 15 Software Engineering, lecture 16+ 17: Modeling in UML 16 Dominance of models System models Object model � The system has classes with nontrivial states and many Functional model relationships between the classes Use case diagrams Dynamic model Object model � The model has many different types of events: input, Class diagrams output, exceptions, errors, etc. Dynamic model Functional model Sequence diagrams � The model performs complicated transformations (e.g., State diagrams computations consisting of many steps) Software Engineering, lecture 16+ 17: Modeling in UML 17 Software Engineering, lecture 16+ 17: Modeling in UML 18 3

  4. UML use case diagrams Actors Actor is potentially An actor models an external entity which involved in the task communicates with the system � Kind of user � External system A use case represents a � Physical environment Client sequence of interaction An actor has a unique name and an optional for a kind of task description Client � Client: A person in the train Actors represent � GPS satellite: An external system that roles, that is, a kind Withdraw provides the system with GPS of user of the system coordinates System boundaries Software Engineering, lecture 16+ 17: Modeling in UML 19 Software Engineering, lecture 16+ 17: Modeling in UML 20 Use case Use case example: Withdraw A use case represents a kind of task Initiating actor: Client provided by the system as an event flow Entry condition A use case consists of � Client has opened a bank account with the bank and � Unique name Withdraw � Client has received a bank card and PIN � Participating actors � Entry conditions Exit condition � Flow of events � Client has the requested cash or � Exit conditions � Client receives an explanation from the Bankomat about � Special requirements why the cash could not be dispensed Software Engineering, lecture 16+ 17: Modeling in UML 21 Software Engineering, lecture 16+ 17: Modeling in UML 22 Use case example: Withdraw event flow Reusing use cases Actor steps System Steps 1. Authenticate Withdraw <<include>> 2. Bankomat displays options 3. Client selects “Withdraw CHF” 4. Bankomat queries amount Load <<include>> Authenticate Cash Card 5. Client enters amount 6. Bankomat returns bank card Client 7. Bankomat outputs specified <<include>> amount in CHF Transfer Details of authentication <<include>> stereotype to include use cases: Anything missing? reusing common functionality, no duplicates Exceptional cases Software Engineering, lecture 16+ 17: Modeling in UML 23 Software Engineering, lecture 16+ 17: Modeling in UML 24 4

Recommend

More recommend