Understanding Abstraction and UML Modeling in Object-Oriented Software Engineering, Schemes and Mind Maps of Software Engineering

Download Understanding Abstraction and UML Modeling in Object-Oriented Software Engineering and more Schemes and Mind Maps Software Engineering in PDF only on Docsity! 1 U si n g U M L , P at te rn s, a n d J av a O b je ct -O ri en te d S o ft w a re E n g in ee ri n g Chapter 2, Modeling with UML, Part 1 2 Odds and Ends • Reading for this Week: • Chapter 1 and 2, Bruegge&Dutoit, Object-Oriented Software Engineering • Lectures Slides: • Will be posted after each lecture. 2 3 Overview for the Lecture • Three ways to deal with complexity • Abstraction and Modeling • Decomposition • Hierarchy • Introduction into the UML notation • First pass on: • Use case diagrams • Class diagrams • Sequence diagrams • Statechart diagrams • Activity diagrams 4 What is the problem with this Drawing? 5 9 We use Models to describe Software Systems • Object model: What is the structure of the system? • Functional model: What are the functions of the system? • Dynamic model: How does the system react to external events? • System Model: Object model + Functional model + Dynamic model 10 Other models used to describe Software System Development • Task Model • PERT Chart: What are the dependencies between tasks? • Schedule: How can this be done within the time limit? • Organization Chart: What are the roles in the project? • Issues Model • What are the open and closed issues? • What blocks me from continuing? • What constraints were imposed by the client? • What resolutions were made? • These lead to action items 6 11 Issue-Modeling Issue: What is the Center of the Universe? Proposal1: The earth! Proposal2: The sun! Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth. 12 Issue-Modeling Issue: What is the Center of the Universe? Proposal1: The earth! Proposal2: The sun! Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth. Resolution (1615): The church decides proposal 1 is right 7 13 Issue-Modeling Issue: What is the Center of the Universe? Proposal1: The earth! Proposal2: The sun! Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth. Resolution (1615): The church decides proposal 1 is right Resolution (1998): The church declares proposal 1 was wrong Proposal3: Neither! Pro: Galaxies are moving away From each other. 14 2. Technique to deal with Complexity: Decomposition • A technique used to master complexity (“divide and conquer”) • Two major types of decomposition • Functional decomposition • Object-oriented decomposition • Functional decomposition • The system is decomposed into modules • Each module is a major function in the application domain • Modules can be decomposed into smaller modules. 10 19 Changing a Square into a Circle 20 Autoshape Functional Decomposition: Autoshape Draw Rectangle Draw Oval Draw Circle Change Draw Change Rectangle Change Oval Change Circle 11 21 Object-Oriented View Autoshape Draw() Change() 22 What is This? Neck Glove Coat Pocket Cave Ellbow An Eskimo! 12 23 Nose Eye Ear Chin Mouth Hair A Face! 24 Nose Eye Ear Chin Mouth Hair Ellbow Neck Glove Coat Pocket Cave A Face!An Eskimo! 15 29 Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth Red White Cortical Pyramidal 30 Where are we now? • Three ways to deal with complexity: • Abstraction, Decomposition, Hierarchy • Object-oriented decomposition is good • Unfortunately, depending on the purpose of the system, different objects can be found • How can we do it right? • Start with a description of the functionality of a system • Then proceed to a description of its structure • Ordering of development activities • Software lifecycle 16 31 Models must be falsifiable • Karl Popper (“Objective Knowledge): • There is no absolute truth when trying to understand reality • One can only build theories, that are “true” until somebody finds a counter example • Falsification: The act of disproving a theory or hypothesis • The truth of a theory is never certain. We must use phrases like: • “by our best judgement”, “using state-of-the-art knowledge” • In software engineering any model is a theory: • We build models and try to find counter examples by: • Requirements validation, user interface testing, review of the design, source code testing, system testing, etc. • Testing: The act of disproving a model. 32 Concepts and Phenomena • Phenomenon • An object in the world of a domain as you perceive it • Examples: This lecture at 9:35, my black watch • Concept • Describes the common properties of phenomena • Example: All lectures on software engineering • Example: All black watches • A Concept is a 3-tuple: • Name: The name distinguishes the concept from other concepts • Purpose: Properties that determine if a phenomenon is a member of a concept • Members: The set of phenomena which are part of the concept. 17 33 Definition Abstraction: • Classification of phenomena into concepts Definition Modeling: • Development of abstractions to answer specific questions about a set of phenomena while ignoring irrelevant details. MembersName Watch Purpose A device that measures time. Concepts, Phenomena, Abstraction and Modeling 34 Abstract Data Types & Classes • Abstract data type • A type whose implementation is hidden from the rest of the system • Class: • An abstraction in the context of object-oriented languages • A class encapsulates state and behavior • Example: Watch Watch time date SetDate(d) CalculatorWatch EnterCalcMode() InputNumber(n) calculatorState Unlike abstract data types, subclasses can be defined in terms of other classes using inheritance State Behavior Inheritance Subclass • Example: CalculatorWatch Superclass 20 39 Systems, Models and Views System View * Model * Depicted byDescribed by Airplane: System Scale Model:Model Flight Simulator:Model Fuel System: View Electrical Wiring: View Blueprints: View (UML Notation) Class Diagram Object Diagram 40 Model-Driven Development 1. Build a platform-independent model of an applications functionality and behavior a) Describe model in modeling notation (UML) b) Convert model into platform-specific model 2. Generate executable from platform-specific model Advantages: • Code is generated from model (“mostly”) • Portability and interoperability • Model Driven Architecture effort: • http://www.omg.org/mda/ • OMG: Object Management Group 21 41 Reality: A stock exchange lists many companies. Each company is identified by a ticker symbol Analysis results in analysis object model (UML Class Diagram): StockExchange Company tickerSymbol Lists ** Implementation results in source code (Java): public class StockExchange { public m_Company = new Vector(); }; public class Company { public int m_tickerSymbol; public Vector m_StockExchange = new Vector(); }; Model-driven Software Development 42 Application vs Solution Domain • Application Domain (Analysis): • The environment in which the system is operating • Solution Domain (Design, Implementation): • The technologies used to build the system • Both domains contain abstractions that we can use for the construction of the system model. 22 43 Object-oriented Modeling Application Domain (Phenomena) Solution Domain (Phenomena) System Model (Concepts) System Model (Concepts) Aircraft TrafficController FlightPlanAirport MapDisplay FlightPlanDatabase Summary Display TrafficControl TrafficControl UML Package (Analysis) (Design) 44 What is UML? • UML (Unified Modeling Language) • Nonproprietary standard for modeling software systems, OMG • Convergence of notations used in object-oriented methods • OMT (James Rumbaugh and collegues) • Booch (Grady Booch) • OOSE (Ivar Jacobson) • Current Version: UML 2.2 • Information at the OMG portal http://www.uml.org/ • Commercial tools: Rational (IBM),Together (Borland), Visual Architect (business processes, BCD) • Open Source tools: ArgoUML, StarUML, Umbrello • Commercial and Opensource: PoseidonUML (Gentleware) 25 49 Historical Remark: UML 1 used packages WatchUser Actor Use casePackage Watch Use case diagrams represent the functionality of the system from user’s point of view ReadTime SetTime ChangeBattery WatchRepairPerson 50 UML first pass: Class diagrams Class Association Multiplicity Class diagrams represent the structure of the system 2 1 1 1 1 1 1 2 SimpleWatch Display Battery TimePushButton 26 51 UML first pass: Class diagrams 1 2 push() release() 1 1 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay Battery Load 1 2 1 Time Now 1 Watch Operations state PushButton Attribute Class diagrams represent the structure of the system Class Association Multiplicity 52 Message UML first pass: Sequence diagram :Time:Watch:WatchUser Object Activation Sequence diagrams represent the behavior of a system as messages (“interactions”) between different objects Actor pressButton1() Lifeline blinkHours() pressButton2() incrementMinutes() :LCDDisplay pressButton1and2() commitNewTime() stopBlinking() refresh() pressButton1() blinkMinutes() 27 53 UML first pass: Statechart diagrams State Initial state Final state Transition Event Represent behavior of a single object with interesting dynamic behavior. button1&2Pressed button1Pressed button2Pressed button2Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking 54 Other UML Notations UML provides many other notations, for example • Deployment diagrams for modeling configurations • Useful for testing and for release management • We introduce these and other notations as we go along in the lectures • OCL: A language for constraining UML models