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