Chapter 2, Modeling with UML, Part 1

Importance of Software Design - 1 We live in a designed world. Design is economically important and effects our quality of life.

Importance of Software Design - 2 Software is becoming ubiquitous. The quality of software design has important consequences that software designers should be aware of and take seriously.

Software Products A software product is an entity comprised of one or more programs, data, and supporting materials and services that satisfies client needs and desires either as an independent artifact or as essential ingredient in some other artifact.

Software Design Defined Software designers do what designers in other disciplines do, except they do it for software products. Software design is the activity of specifying the mature and composition of software products that satisfy client needs and desire, subject to constraints. Yazılım tasarımı, verilen kısıtlar dahilinde, müşterilerin beklentilerini tatmin eden bileşimi belirleme faaliyetidir.

Design as Problem Solving An especially fruitful way to think about design is as problem solving. Advantages Suggests partitioning information between problem and solution Emphasizes that there may be more than one good solution (design) Suggests techniques such as changing the problem, trial and error, brainstorming, etc.

What is the problem with this Drawing?

1. Abstraction Abstraction is an important problem-solving technique, especially in software design. Abstraction is suppressing or ignoring some properties of objects, events, or situations in favor of others.

Abstraction Complex systems are hard to understand The 7 +- 2 phenomena / Miller’s Law / Miller’s Magic Number (George A. Miller, 1956, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review) Our short term memory (15-30 seconds) cannot store more than 7+-2 pieces at the same time -> limitation of the brain TUM Phone Number: 498928918204

Abstraction Complex systems are hard to understand Chunking: The 7 +- 2 phenomena (G.A. Miller, 1956, The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, Psychological Review) Our short term memory cannot store more than 7+-2 pieces at the same time -> limitation of the brain TUM Phone Number: 498928918204 Chunking: Group collection of objects to reduce complexity 4 chunks: State-code, city-code, TUM-code, Office-Part

Abstraction Complex systems are hard to understand Chunking: The 7 +- 2 phenomena Our short term memory cannot store more than 7+-2 pieces at the same time -> limitation of the brain TUM Phone Number: 498928918204 Chunking: Group collection of objects to reduce complexity State-code, city-code, TUM-code, Office-Part TUM Phone Number State-Code City-Code TUM-Code Office-Part

Importance of Abstraction Problem simplification Abstracting allows us to focus on the most important aspects of a problem in (partially) solving it. Structuring problem solving Top-down strategy: Solve an abstract version of the problem, then add details (refinement) Bottom-up strategy: Solve parts of a problem and connect them for a complete solution Denilebilir ki: Soyutlama esaslı top-down strateji, geniş ölçekli tasarım problemlerinde görülen dominant problem çözme stratejisidir.

Abstraction Abstraction allows us to ignore unessential details Ideas can be expressed by models A scale model is a replica or prototype of an object built either for research or as a hobby, usually built smaller than the existing or intended thing, though can equally be built larger to illustrate something that would otherwise be hard to see.

Modeling A model represents a target by having model parts corresponding to target parts, with relationships between model parts corresponding to relationships between target parts.

Model A model is an abstraction of a system A system that no longer exists An existing system A future system to be built.

Modeling in Design Modeling is used for the following purposes: Problem understanding Design creation and investigation Documentation Modeling work because models abstract details of the target. Models can fail if important and relevant details are left out. Problemi Anlamak: Tasarımcılar çözüm önermeden önce, problemleri ve kısıtlarını anlamalıdırlar. Modeller bu noktada işe yarar. Tasarımı Yaratmak ve Soruşturmak: Yerleştirme planları, çizilen şemalar, diyagramlar bir çok disiplinde tasarımın yapı taşlarıdır. Belgeleme: Modeller, uygulamaya geçilmeden önce, yapılan tasarımların belgelendirilmesini de sağlar. Yazılım tasarımında modellemenin yeri nedir? Yazılım tasarımlarında genelde sembolik ifadelerdir. Yazılımı modellerken, birden fazla yöntem kullanılır.

Static and Dynamic Models A static design model represents aspects of programs that do not change during program execution. A dynamic model represents what happens during program execution. Static model examples include class and object models. Dynamic model examples of include state diagrams and sequence diagrams.

Product vs. Engineering Design Product designers are concerned with styling and aesthetics, function and usability, manufacturability and manageability. Industrial designers, (building) architects, interior designers, graphic designers, etc. Engineering designers are concerned with technical mechanisms and workings. Structural, mechanical, chemical, and electrical engineers Design teams often include both product and engineering designers.

Software Product Design Software product design is the activity of specifying software product features, capabilities, and interfaces to satisfy client needs and desires. Requires skills in user interface and interaction design, communications, industrial design, and marketing

Software Engineering Design Software engineering design is the activity of specifying programs and sub-systems, and their constituent parts and workings, to meet software product specifications. Requires skills in programming, algorithms, data structures, software design principles, practices, processes, techniques, architectures, and patterns

Software Design In summary, the field of software design can be divided into two sub-fields that each demand considerable skill and expertise: Software product design and software engineering design.

Software Design in the Life Cycle The software life cycle is the sequence of activities through which a software product passes from initial conception through retirement from service.

Waterfall Life Cycle Model The waterfall model captures the logical, but not the temporal, relationships between software development activities.

Design Across the Life Cycle

“What” Versus “How” Traditional way to make the distinction between requirements and design activities Not adequate because Many “what” specifications turn out to be design decisions Many “how” specifications turn out to be client or customer needs or desires Distinguish requirements from design based on problem solving: requirements activity formulates a problem solved in design

Design Problems and Solutions

Software Design Method A software design method is an orderly procedure for generating a precise and complete software design solution that meets clients needs and constraints.

Design Method Components Design Process—A collection of related tasks that transforms a set of inputs into a set of outputs Design Notations—A symbolic representational system Design Heuristics—Rules providing guidance, but no guarantee, for achieving some end Design methods also use design principles stating characteristics of design that make them better or worse.

Design Method Timeline Niklaus Wirth introduces stepwise refinement. Stevens, Myers, Constantine introduce structured design. Late 1970s to early 1980s Structured analysis and design methods are dominant. Late 1980s Object-oriented analysis and design methods rise to prominence. 1995 UML 0.8 is released. 2004 UML 2.0 is released.

We use Models to describe Software Systems Object model: What is the structure of the system? What are the objects and how theya re related? Functional model: What are the functions of the system? How is data flowing through the system? Dynamic model: How does the system react to external events? System Model: Object model + functional model + dynamic model

Other models used to describe Software System Development Task Model: PERT (Project Evaluation and Review Technique) 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

PERT Chart - 1 It is a project management tool used to schedule, and coordinate tasks within a project. Similar methodology for private sector -> Critical Path Method (CPM) A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (circles or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) representing tasks.

PERT Chart - 2

PERT Chart - 3 Örneğin: C işinin en erken başlama süresi max(6,9)=9.

PERT Chart - 4 İşlerin en erken başlama süreleri.

The “Bermuda Triangle” of Modeling

Jupiter’s moons rotate 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.

Jupiter’s moons rotate Issue-Modeling Issue: What is the Center of the Universe? Resolution (1615): The church decides proposal 1 is right 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.

Galaxies are moving away Jupiter’s moons rotate Issue-Modeling Issue: What is the Center of the Universe? Resolution (1998): The church declares proposal 1 was wrong Resolution (1615): The church decides proposal 1 is right Proposal1: The earth! Proposal3: Neither! Proposal2: The sun! Pro: Galaxies are moving away From each other. Pro: Copernicus says so. Pro: Aristotle says so. Pro: Change will disturb the people. Con: Jupiter’s moons rotate around Jupiter, not around Earth.

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 See the presentation: “Using functional analysis to determine the requirements for changes to critical systems: Railway level crossing case study”

Technique to deal with Complexity: 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. Functions are spread over the system -> Hard to maintain / change.

Decomposition (cont’d) Object-oriented decomposition Very useful after initial functional description -> Object Design The system is decomposed into classes (“objects”) Each class is a major entity in the application domain Classes can be decomposed into smaller classes Encapsulates data and functions -> Helps to deal with change Object-oriented vs. functional decomposition Which decomposition is the right one?

Functional Decomposition System Function Top Level functions Read Input Produce Output Transform Level 1 functions Read Input Transform Produce Output Level 2 functions Load R10 Add R1, R10 Machine instructions

Our First Modeling Project! What is This? An Eskimo! Cave Neck Ellbow Glove Pocket Coat

Our First Modeling Project! Model of an Eskimo

A Face! Hair Eye Nose Ear Mouth Chin

Our First Modeling Project! Alternative Model: The Head of an Indian

An Eskimo! A Face! Cave Hair Neck Eye Ellbow Nose Ear Glove Pocket Mouth Coat Chin

Class Identification Basic assumptions: Class identification is crucial to object-oriented modeling. Basic assumptions: We can find the classes for a new software system: Greenfield Engineering We can identify the classes in an existing system: Reengineering We can create a class-based interface to an existing system: Interface Engineering

Class Identification (cont’d) Why can we do this? Philosophy, science, experimental evidence What are the limitations? Depending on the purpose of the system, different objects might be found Crucial Identify the purpose of a system

3. Hierarchy So far we got abstractions This leads us to classes and objects “Chunks” A hierarchy (in greek: hieros, sacred, and arkho, rule) is a system of organizing things. Another way to deal with complexity is to provide relationships between these chunks One of the most important relationships is hierarchy 2 special hierarchies "Part-of" hierarchy "Is-kind-of" hierarchy

Part-of Hierarchy (Aggregation) Computer I/O Devices CPU Memory Cache ALU Program Counter

Example of Aggregation -1 A car class can be defined to contain other classes such as engine class, seat class, wheels class etc. “A car object is an aggregation of engine, seat, wheels and other objects.”

Is-Kind-of Hierarchy (Taxonomy) Cell Muscle Cell Blood Cell Nerve Cell Striate Smooth Red White Cortical Pyramidal

Example of Taxonomy -1 Male, Female is a kind of Person.

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

Models must be falsifiable Karl Popper (1902-1994) (“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.

Concepts and Phenomena Phenomenon An object in the world of a domain as you perceive it Examples: This lecture at 9:00, 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. Phenomenon (olgu, algılanılabilen şey): Gerçek hayatta ki bir nesnenin, modeli yapan tarafından algılanış biçimi. Örneğin 9’daki ders, siyah saatim. Concepts (kavram): Fenomenlerin ortak özelliklerine denir. (Geçelim....) Her bir concept’in 3 özelliği vardır. O yüzden her bir concept’i bir 3-tuple ile anlatıyoruz: Adı: Conceptleri birbirinden ayırmak için Amaç: Bir fenomenin, o konseptin elemanı olup olmadığını gösteren özellik Üyeler: Bir conceptin parçası olan fenomenlerin kümesi.

Concepts, Phenomena, Abstraction and Modeling Name Purpose Members A device that measures time. Watch 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.

Abstract Data Types & Classes Superclass State Abstract data type (ADT) 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 Behavior Inheritance Unlike abstract data types, subclasses can be defined in terms of other classes using inheritance Example: CalculatorWatch Subclass

Attention!!!

Class Example

Inheritance Examples (Classes and subclasses) - 1 is-kind-of = inheritance

Inheritance Examples (Classes and subclasses) - 2

Type and Instance Type: Instance: A concept in the context of programming languages Name: int Purpose: integral number Members: 0, -1, 1, 2, -2,… Instance: Member of a specific type The type of a variable represents all possible instances of the variable The following relationships are similar: Type <–> Variable Concept <–> Phenomenon Class <-> Object

Systems A system is an organized set of communicating parts Natural system: A system whose ultimate purpose is not known Engineered system: A system which is designed and built by engineers for a specific purpose The parts of the system can be considered as systems again In this case we call them subsystems Examples of natural systems: • Universe, earth, ocean Examples of engineered systems: • Airplane, watch, GPS Examples of subsystems: • Jet engine, battery, satellite.

Systems, Models and Views • A model is an abstraction describing a system or a subsystem • A view depicts selected aspects of a model A notation is a set of graphical or textual rules for depicting models and views: formal notations, “napkin designs” System: Airplane Models: Flight simulator Scale model Views: Blueprint of the airplane components Electrical wiring diagram, Fuel system Sound wave created by airplane

Systems, Models and Views (“Napkin” Notation) Flightsimulator Aircraft Fuel System Electrical Wiring Blueprints Scale Model Views and models of a complex system usually overlap

Systems, Models and Views (UML Notation) Class Diagram System Model * View * Depicted by Described by Airplane: System Object Diagram Scale Model:Model Flight Simulator:Model Blueprints: View Fuel System: View Electrical Wiring: View

An Example of Object Diagram

Model-Driven Development (MDD) Build a platform-independent model (PIM) of an applications functionality and behavior a) Describe model in modeling notation (UML) b) Convert model into platform-specific model Generate executable from platform-specific model Advantages: Code is generated from model (“mostly”) Portability and interoperability Model Driven Architecture (MDA) effort: http://www.omg.org/mda/ OMG: Object Management Group

Application vs Solution Domain Application Domain (Analysis): The environment in which the system is operating It changes over time, as work processes and people changes. 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.

Object-oriented Modeling Solution Domain (Phenomena) Application Domain (Phenomena) System Model (Concepts) (Analysis) System Model (Concepts) (Design) UML Package Summary Display MapDisplay TrafficControl FlightPlanDatabase TrafficController TrafficControl Aircraft Airport FlightPlan

What is UML? UML (Unified Modeling Language) Current Version: UML 2.2 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, LucidChart Commercial and Opensource: PoseidonUML (Gentleware) UML: Sahibi olmayan, yazılım sistemi modelleme dili. OMG: Object Management Group

What is UML? Unified Modeling Language Convergence of different notations used in object-oriented methods, mainly OMT (James Rumbaugh and collegues), OOSE (Ivar Jacobson), Booch (Grady Booch) They also developed the Rational Unified Process, which became the Unified Process in 1999 At Ericsson until 1994, developed use cases and the CASE tool Objectory, at IBM Rational since 1995, http://www.ivarjacobson.com 25 year at GE Research, where he developed OMT, joined (IBM) Rational in 1994, CASE tool OMTool Developed the Booch method (“clouds”), ACM Fellow 1995, and IBM Fellow 2003 http://www.booch.com/

UML: First Pass You can model 80% of most problems by using about 20% UML We teach you those 20% 80-20 rule: Pareto principle: For many events, roughly 80% of the effects come from 20% of the causes. Vilfredo Pareto, 1848-1923 Introduced the concept of Pareto Efficiency, Founder of the field of microeconomics.

UML First Pass Use case diagrams Class diagrams Sequence diagrams Describe the functional behavior of the system as seen by the user Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams Describe the dynamic behavior between objects of the system Statechart diagrams Describe the dynamic behavior of an individual object Activity diagrams Describe the dynamic behavior of a system, in particular the workflow.

UML Core Conventions All UML Diagrams denote graphs of nodes and edges Nodes are entities and drawn as rectangles or ovals Rectangles denote classes or instances Ovals denote functions Names of Classes are not underlined SimpleWatch Firefighter Names of Instances are underlined myWatch:SimpleWatch Joe:Firefighter An edge between two nodes denotes a relationship between the corresponding entities

UML first pass: Use case diagrams Classifier Use Case Actor. System boundary Use case diagrams represent the functionality of the system from user’s point of view

UML first pass: Class diagrams Association Class Multiplicity SimpleWatch 1 2 1 2 PushButton Display Battery Time Class diagrams represent the structure of the system

UML first pass: Class diagrams Class diagrams represent the structure of the system Association Class Multiplicity Watch 1 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay 1 Battery Load 1 2 Time Now 1 1 2 PushButton state push() release() Operations Attribute

UML first pass: Sequence diagram :Watch :WatchUser Actor Message Object Lifeline :LCDDisplay :Time pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButton1and2() commitNewTime() stopBlinking() Activation Sequence diagrams represent the behavior of a system as messages (“interactions”) between different objects

UML first pass: Statechart diagrams Initial state Event button1&2Pressed button1Pressed button2Pressed Increment Minutes Hours Blink Seconds Stop Blinking Transition State Final state Represent behavior of a single object with interesting dynamic behavior.

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

What should be done first? Coding or Modeling? It all depends…. Forward Engineering Creation of code from a model Start with modeling Greenfield projects Reverse Engineering Creation of a model from existing code Interface or reengineering projects Roundtrip Engineering Move constantly between forward and reverse engineering Reengineering projects Useful when requirements, technology and schedule are changing frequently.

Additional References Martin Fowler UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd ed., Addison-Wesley, 2003 Grady Booch,James Rumbaugh,Ivar Jacobson The Unified Modeling Language User Guide, Addison Wesley, 2nd edition, 2005 Commercial UML tools Rational Rose XDE for Java http://www-306.ibm.com/software/awdtools/developer/java/ Together (Eclipse, MS Visual Studio, JBuilder) http://www.borland.com/us/products/together/index.html Open Source UML tools http://java-source.net/open-source/uml-modeling ArgoUML,UMLet,Violet, … Also: - Together Designer 2006 for Eclipse - Together Designer 2005, for Microsoftｨ Visual Studio.NET 2003 - Together Designer 2005, for JBuilderｨ 2005