1. Chapter 2, Modeling with UML, Part 1

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

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

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

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

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

7. What is the problem with this Drawing?

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

9. Abstraction Complex systems are hard to understand
The 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:

10. Abstraction Complex systems are hard to understand Chunking:
The 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:
Chunking:
Group collection of objects to reduce complexity
4 chunks:
State-code, city-code, TUM-code, Office-Part

11. Abstraction Complex systems are hard to understand Chunking:
The phenomena
Our short term memory cannot store more than 7+-2 pieces at the same time -> limitation of the brain
TUM Phone Number:
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

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

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

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

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

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

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

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

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

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

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

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

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

24. Design Across the Life Cycle

25. “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

26. Design Problems and Solutions

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

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

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

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

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

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

33. PERT Chart - 2

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

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

36. The “Bermuda Triangle” of Modeling

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

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

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

40. 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”

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

42. 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?

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

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

45. Our First Modeling Project! Model of an Eskimo

46. A Face!
Hair
Eye
Nose
Ear
Mouth
Chin

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

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

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

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

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

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

53. 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.”

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

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

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

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

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

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

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

61. Attention!!!

62. Class Example

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

64. Inheritance Examples (Classes and subclasses) - 2

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

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

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

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

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

70. An Example of Object Diagram

71. 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:
OMG: Object Management Group

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

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

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

75. 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,
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

76. 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,
Introduced the concept of Pareto Efficiency,
Founder of the field of microeconomics.

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

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

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

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

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

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

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

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

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

86. 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
Together (Eclipse, MS Visual Studio, JBuilder)
Open Source UML tools
ArgoUML,UMLet,Violet, …
Also:
- Together Designer 2006 for Eclipse
- Together Designer 2005, for Microsoftｨ Visual Studio.NET 2003
- Together Designer 2005, for JBuilderｨ 2005