소프트웨어 개발론 과목 소개 2장.

UML 모델링

1장: 소프트웨어공학 소개

안성수
소프트웨어공학과
 Profession
A Physician, a Civil Engineer and a Computer Scientist were arguing about
what was the oldest profession in the world.

 The Physician remarked,

"Well, in the Bible, it says that God created Eve from a rib taken out of Adam. This
clearly requires surgery, and so I can rightly claim that mine is the oldest profession in
the world."

 The Civil Engineer interrupted, and said,

" But even earlier in the book of Genesis, it states that God created the order of the
heavens and the earth from out of the chaos. This was the first and certainly the most
spectacular application of civil engineering. Therefore, fair doctor, you are wrong; mine
is the oldest profession in the world.“

 The Computer Scientist leaned back in the chair, smiled

and then said confidently,
"Ah, but what do you think created the chaos ? "
Source: Lawrence Chung, Lecture slide of Advanced Software Engineering, UT Dallas
Object-Oriented Software Engineering
Using UML, Patterns, and Java
Software Engineering
Chapter 1: Introduction to
Outline of Today’s Lecture
 Software Engineering Failures
 What is Software Engineering?
 Software Engineering Concepts
 Software Engineering Development Activities
 Managing Software Development
 Team Project

4
Software Engineering Failures
 Year 1900 bug
 1992년, 미네소타 위노나에 거주하는 104세인 메리가 유치원 취학통지서를 받음
 Leap-Year bug
 1998년 2월 29일, 한 슈퍼마켓은 가공 육류를 1일 더 판매해, 유통기한 (2월 28일) 위반으로
$1000 벌금 통지서를 받음
 Interface misuse
 1990년 4월 10일, 지하철 열차가 운전사 없이 지하철 역을 출발함.
 운전사는 ‘출발＇버튼을 테이프로 감싸 놓고, 지하철에서 나와 닫히지 않는 문을 닫음. 지하철 열차는
문이 열려 있을 경우 출발하지 않으나, 문이 닫히자 열차는 출발함.
 Late and over budget
 1995년, 덴버 공항, 자동 수하물 시스템 오류로 16개월 지연 후 공항 운영시작, $32억 달러 예산
초과됨
 Unnecessary complexity
 C-17 화물운송기 제작에 5억 달러 이상의 초과 예산 소요됨. 19개 탑재 컴퓨터, 80개
마이크로프로세서, 6개 서로다른 프로그램 언어 사용
- 개발자는 흔치 않은 상황을 예측하지 못했음
- 개발자는 시스템을 잘못 사용할 것을 예측하지 못했음 5
- 소프트웨어 관리를 제대로 하지 못해, 예산 초과, 납기 지연 등이 발생함
Software Production has a Poor Track Record
Example: Space Shuttle Software
 Cost: $10 Billion, millions of dollars more than planned
 Time: 3 years late
 Quality: First launch of Columbia (on April 10, 1981) was cancelled
because of a synchronization problem with the Shuttle's 5 onboard
computers.
 Error was traced back to a change made 2 years earlier when a programmer
changed a delay factor in an interrupt handler from 50 to 80 milliseconds.
 The likelihood of the error was small enough, that the error caused no harm
during thousands of hours of testing.
 Substantial errors still exist.
 Astronauts are supplied with a book of known software problems "Program
Notes and Waivers".

6
Source: THE "BUG" HEARD 'ROUND THE WORLD, https://dl.acm.org/doi/pdf/10.1145/1005928.1005929
Can you develop this system?
Can you develop this system?
Can you develop this system?
Can you develop this system?

The impossible
Fork
Physical Model of the impossible Fork (Shigeo Fukuda)
Why is software development difficult?
 The problem domain (also called application domain) is difficult
 The solution domain is difficult
 The development process is difficult to manage
 Software offers extreme flexibility
 Software is a discrete system
 Continuous systems have no hidden surprises
 Discrete systems can have hidden surprises! (Parnas)
David Lorge Parnas is an early pioneer in
software engineering who developed the
concepts of modularity and information hiding
in systems which are the foundation of
object oriented methodologies.
12
Software Engineering is more than writing Code
 Modeling activity
 Dealing with complexity through modeling
 Problem solving activity
 Models are used to search for an acceptable solution
 Knowledge acquisition activity
 Collecting data, organizing it into information, and formalizing it into
knowledge
 Rationale-driven activity
 When making decisions, software engineers need to capture the context and
rationale behind these decisions

13
Software Engineering: Modeling Activity
 The goal of science is to describe and understand complex systems
 E.g., a system of atoms, a society of human beings, or a solar system
 One of the basic methods of science is modeling
 A model is an abstract representation of a system that enables us to answer
questions about the system
 Models are useful when dealing with systems that are too large, too small,
too complicated, or too expensive to experience firsthand
 Software engineers need to understand
 The environment in which the system has to operate
 The systems they could build, to evaluate different solutions and trade-offs
Object-oriented methods combine application domain and
solution domain modeling activities into one 14
Software Engineering: Problem Solving Activity
 Engineering is a problem-solving activity
 Engineering method include five steps, in its simplest form
1. Formalize the problem
2. Analyze the problem
3. Search for solutions
4. Decide on the appropriate solution
5. Specify the solution

 Object-oriented software development typically includes six activities:

1) Requirements elicitation, 2) analysis, 3) system design, 4) object design,
5) implementation, and 6) testing
15
Software Engineering: Knowledge Acquisition Activity

 Developers need to understand stakeholder needs and their problems

during requirements elicitation
 Developers also need to acquire domain knowledge

 Knowledge acquisition is a nonlinear process

 The addition of a new piece of information may invalidate all the knowledge
we have acquired for the understanding of a system

16
Software Engineering: Rationale Activity
 Rationale is the justification of decisions
 Given a decision, its rationale includes
 The problem that it addresses
 The alternatives that developers considered
 The criteria that developers used to evaluate alternatives
 The debate developers went through to achieve consensus, and
 Decisions

 For example, to change the system, it is not enough to understand its

current component and behavior. It is also necessary to capture and
understand the context in which each design decision was made
17
다음 항목에 팀/그룹별로 논의하시오
1. 본인이 알고 있는 소프트웨어 모델링 기법을 나열하고 언제
유용한지 논의하시오.

2. 아래 분야별 문제해결을 위한 일반적인 절차(단계)에 대해

논의하시오.
 수학 문제
 소프트웨어공학 문제
 항공우주공학 문제

• 팀/그룹별 발표자를 선정할 것. 발표자가 팀/그룹에서 논의한 내용을 요약해 발표 18

Computer Science vs. Engineering
 Computer Scientist
 Assumes techniques and tools have to be developed.
 Proves theorems about algorithms, designs languages, defines knowledge
representation schemes
 Has infinite time…
 Engineer
 Develops a solution for a problem formulated by a client
 Uses computers & languages, techniques and tools
 Software Engineer
 Works in multiple application domains
 Has only 3 months...
 …while changes occurs in the problem formulation (requirements) and also in
the available technology.
19
Software Engineering: A Working Definition
Software Engineering is a collection of techniques,
methodologies and tools that help with the
production of

A high quality software system developed with a given

budget before a given deadline while change occurs

Challenge: Dealing with

complexity and change

20
Factors affecting the quality of a software system
 Complexity:
 The system is so complex that no single programmer can understand it
anymore
 The introduction of one bug fix causes another bug

 Change:
 The “Entropy” of a software system increases with each change: Each
implemented change erodes the structure of the system which makes the
next change even more expensive
 As time goes on, the cost to implement a change will be too high, and the
system will then be unable to support its intended task. This is true of all
systems, independent of their application domain or technological base

21
 Complex Server Connections

22
Source: Lawrence Chung, Advanced Software Engineering, Lecture Slide, UT Dallas
 Complex Message Flow

How to deal with these complexity?

23
Source: Lawrence Chung, Advanced Software Engineering, Lecture Slide, UT Dallas
Software Engineering: A Problem Solving Activity
 Analysis:
 Understand the nature of the problem and break the problem into pieces
 Synthesis:
 Put the pieces together into a large structure

For problem solving we use techniques, methodologies and tools.

24
Techniques, Methodologies and Tools
 Techniques:
 Formal procedures for producing results using some well-defined notation
 Use case modeling
 Algorithms, cook book recipes are examples of techniques
 Methodologies:
 Collection of techniques applied across software development and unified by
a philosophical approach
 Object-Oriented Software Engineering
 A cookbook is a methodology
 Tools:
 Instruments or automated systems to accomplish a technique
 CASE = Computer Aided Software Engineering
 Examples of tools are: Pans, pots and stove

25
다음 항목에 팀/그룹별로 논의하시오
 A passenger aircraft is composed of several millions of individual parts
and requires thousands of persons to assemble.
 A four-lane highway bridge is another example of complexity. The first
version of Word for Windows, a word processor released by Microsoft
in November 1989, required 55 person-years, resulted into 249,000
lines of source code, and was delivered 4 years late.
 Aircraft and highway bridges are usually delivered on time and below
budget, whereas software is often not.
 Discuss what are, in your opinion, the differences between developing an
aircraft, a bridge, and a word processor, which would cause this situation.

• 팀/그룹별 발표자를 선정할 것. 발표자가 팀/그룹에서 논의한 내용을 요약해 발표 26

Software Engineering Concepts

Depicted as
a UML class diagram

27
TicketDistributor System (Software) 개발하기
 TicketDistributor is a machine that distributes tickets for trains.
 Travelers have the option of selecting a ticket for a single trip or for
multiple trips, or selecting a time card for a day or a week.
 The TicketDistributor computes the price of the requested ticket
based on the area in which the trip will take place and whether the
traveler is a child or an adult.
 The TicketDistributor must be able to handle several exceptions, such
as travelers who do not complete the transaction, travelers who
attempt to pay with large bills, and resource outages, such as running
out of tickets, change, or power.

28
Participants and Roles
 Participants: all the persons involved in the project
 The same participant can fill multiple roles
 Roles: a set of responsibilities in the project or the system
 A role is associated with a set of tasks and is assigned to a participant

 Some roles in TicketDistributor project are

 Client
 User
 Manager
 Human Factors Specialist
 Developer
 Technical Writer
29
Example of roles
in software engineering
for the TicketDistributor
Project

30
Systems and Models
 System: a collection of interconnected parts
 A TicketDistributor for an underground train is a system

 Model: any abstraction of the system

 Blueprints for the TicketDistributor, schematics of its electrical wiring, and
object models of its software are models of TicketDistributor

 Modeling is a way to deal with complexity by ignoring irrelevant

details

31
Work Products
 Work product: an artifact that is produced during the development
 E.g.: a document or a piece of software for other developers or for the client

 Internal work product: A work product for the project’s internal

consumption

 Deliverable: a work product that must be delivered to a client

32
Examples of work products for the
TicketDistributor Project

33
Activities, Tasks, and Resources
 An activity is a set of tasks that is performed toward a specific
purpose
 E.g., requirements elicitation, delivery, or management
 Activities are also sometimes called phases
 A task represents an atomic unit of work that can be managed
 Tasks consumes resources, result in work products, and depend on work
products produced by other tasks
 Resources are assets that are used to accomplish work
 Resources include time, equipment, and labor
 When planning a project, a manager breaks down the work into tasks and
assigns them to resources

34
Examples of activities, tasks, and resources for
the TicketDistributor Project

35
Functional and Nonfunctional Requirements
 Requirements specify a set of features that the system must have.
 A functional requirement is a specification of a function that the
system must support
 The user must be able to purchase tickets
 The user must be able to access tariff information
 A nonfunctional requirement is a constraint on the operation of the
system that is not related directly to a function of the system.
 The user must be provided feedback in less than one second
 The colors used in the interface should be consistent with the company colors

36
Notations, Methods, and Methodologies
 A notation is a graphical or textual set of rules for representing a
model
 The Roman alphabet is a notation for representing words
 UML (Unified Modeling Language) is a notation for representing object-
oriented models
 Data flow diagrams is a notation for representing systems in terms of data
sources, data sinks, and data transformations
 A method is a repeatable technique that specifies the steps involved
in solving a specific problem.
 A recipe is a method for cooking a specific dish.
 A sorting algorithm is a method for ordering elements of a list.
 Rationale management is a method for justifying change.
 Configuration management is a method for tracking change. 37
Notations, Methods, and Methodologies
 A methodology is a collection of methods for solving a class of
problems and specifies how and when each method should be used
 A seafood cookbook with a collection of recipes is a methodology for
preparing seafood if it also contains advice on how ingredients should be
used and what to do if not all ingredients are available.
 Software development methodologies decompose the process into
activities. Examples of such activities are:
 Analysis, which focuses on formalizing the system requirements into an object
model,
 System Design, which focuses on strategic decisions,
 Object Design, which transforms the analysis model into an object model that
can be implemented

38
Software Engineering Development Activities
 Requirements Elicitation
 Analysis
 System Design
 Object Design
 Implementation
 Testing

39
An overview of object-oriented
software engineering development
activities and their products

40
Requirements Elicitation
 The client and developers define the purpose of the system during
requirements elicitation

 The result of this activity is a description of the system in terms of

actors and use cases
 Actors represent the external entities that interact with the system
 Use cases are general sequences of event that describe all the possible
actions b/w an actor and the system for a given piece of functionality

What other deliverables should be produced during elicitation?

41
Use case: PurchaseOnewayTicket

42
Analysis
 Developers produce a model of the system that is correct, complete,
consistent, and unambiguous during analysis
 Developers transform use cases into an object model that describes the
system
 Developers discover ambiguities and inconsistencies in the use case model
that they resolve with the client

 The system model can be described in terms of its structure and its
dynamic interpretation

43
System model: TicketDistributor

An object model for the

TicketDistributor

A dynamic model for the

TicketDistributor
44
System Design
 Developers define the design goals of the project and decompose the
system into smaller subsystems that can be realized by individual
teams during system design. Developers also select strategies for
building the system
 The hardware/software platform on which the system will run
 The persistent data management strategy
 The global control flow
 The access control policy
 The handling of boundary condition
 The result of system design
 A clear description of each of these strategies
 A subsystem decomposition
 A deployment diagram representing the hardware and software mapping of
the system
45
A subsystem decomposition for the
TicketDistributor
• TravelerInterface subsystem
• Collecting input from the Traveler and
providing feedback
• LocalTariff subsystem
• Computes the price of different
tickets based on a local database
• CentralTariff subsystem
• Maintains a reference copy of the
tariff database
• Updater subsystem TicketDistributor 패키지 다이어그램
• Updating the local databases at each
TicketDistributor through a network 참고: 점선(dashed lines)은 의존성(dependency)을 표현함
when ticket prices change

46
Object Design
 During object design, developers define solution domain objects to
bridge the gap between the analysis model and the
hardware/software platform defined during system design.
 Describing object and subsystem interfaces
 Selecting off-the-shelf components
 Restructuring the object model to attain design goals (e.g., extensibility)
 Optimizing the object model for performance

 The result of object design activities

 A detailed object design model annotated with constraints and precise
descriptions for each element

47
Implementation, Testing
 Developers translate the solution domain model into source code
during implementation
 Mapping UML models to Java or C++ source codes

 Developers find differences between the expected system behavior

and its actual one by executing the system (or parts of it) with sample
input data sets during testing
 Some type of testing includes unit testing, integrating testing, system testing

48
Managing Software Development
 Activities involved in managing a software engineering project include
 Communication
 Rationale Management
 Software Configuration Management
 Project Management
 Software Life Cycle

 We will discuss the above topics if we have time during the semester
Note: Software maintenance activity is not covered in the book

49
Activities for Managing
Software Development

50
Team Project
 프로젝트 팀
 4-5인 1팀으로 구성

 프로젝트 주제, 범위
 프로젝트 주제: 소프트웨어 시스템 개발과 관련된 프로젝트로 개별
팀에서 자체적으로 정의
 프로젝트 범위 한 학기 동안 팀에서 수행할 수 있을 정도의 프로젝트
 개발 프로젝트 종류
 Standalone 시스템
 웹/앱 시스템
 임베디드 시스템 (예: 드론 소프트웨어)
 통합된 시스템

51
Team Project
 프로젝트 평가 기준
 객체지향 소프트웨어공학 기법을 적용한 프로젝트 수행
 적합한 문제 정의
 해결방안 탐색, 평가, 및 적용하여 소프트웨어 시스템의 문제 해결 여부
 소프트웨어 시스템의 기능/비기능 서비스 품질
 객체지향 소프트웨어공학 기법을 적용한 프로젝트 수행 프로세스 품질
 객체지향 소프트웨어공학 기법을 적용한 산출물 품질 및 산출물간
관계간 적절성, 이해 용이성, 추적성
 프로젝트 계획서
 프로젝트 비전 문서
 객체지향 소프트웨어공학 단계별 산출물(artefacts)
 요구사항 도출/분석, 시스템/객체 디자인, 구현 소스, 테스팅 문서,
사용자 매뉴얼, 보조 산출물 등
 프로젝트 발표자료
 프로젝트 동료평가
52
Team Project Schedule
• 프로젝트 계획서 제출 • 팀 프로젝트 최종산출물 제출,
발표, 평가
• 9/10(화) 제출
• 9/12(목) 계획서 발표 (3분) • 12/8(일) 제출, 12/10(화) 발표
• 검토, 상담 (팀 + 교수) • 평가의견 제공
• 학기 프로젝트의 목표, 범위, • 팀 프로젝트 – 동료평가
적합여부 검토/피드백
• 12/12(화)
• 비전문서 제출
• 9/24(화)
• 중간/최종 프로젝트 산출물
• 검토의견 제공
• 업데이트된 프로젝트 계획서
• 팀 프로젝트 중간 발표, 산출물 • 업데이트된 비전문서
제출, 발표, 평가 • 요구사항 도출/분석,
• 10/20(일) 제출, 10/22(화) 발표 시스템/객체 디자인, 구현 소스,
테스팅 문서, 사용자 매뉴얼 등
• 평가의견 제공 53
Any Questions?
E-mail: [email protected]

54