UML Overview [1/2] - KAIST

UML Overview [1/2]Young-Min Baek1 and Doo-Hwan Bae2

1,2Korea Advanced Institute of Science and Technology (KAIST)Daejeon, Republic of Korea

1 [email protected] [email protected]

2017 SpringCS350 Introduction to Software Engineering

Software Engineering Lab (SELab), KAIST

Outline 1. Modeling a Software SystemA. What is Modeling?

B. Modeling Languages

2. Unified Modeling Language (UML)A. What is UML?

B. UML Diagram Taxonomy

C. Software Modeling with UML

3. Design Activities with UMLA. Development Process

B. Types of UML Diagrams

• Structural Diagrams

• Behavioral Diagrams

2017 Spring. [CS350] Introduction to Software Engineering – UML Overview [1/2] 2/53

TA Office Hour

TUE/THU 14:30~17:30 Young-Min Baek, Mingyu Jin

Software Engineering Lab, N1 #524

[email protected]@se.kaist.ac.kr

Notice

3/53

Better SoftwareMore reliable, less defects, better performance,

higher quality, more familiar/comfortable interface, and so on

THEN HOW?

We Want

Software Engineering

4/53

SystematicallyThorough analysis of stakeholders & requirements,

better process, unambiguous understandings

However,High complexity of a large project

(A large number of components & a large amount of team work)

Linguistic communication between teams or between team members is neither accurate nor reliable

How to Develop a System?

5/53

THEN HOW?

Models are the standard representations and they are accurate and reliable.

How to Develop a System?

Model-based/driven Engineering

https://www2.warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/students/david_goodwin/teaching/modelling/l1_introuml.pdf 6/53

https://www2.warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/students/david_goodwin/teaching/modelling/l1_introuml.pdf

Modeling a Software System


Process-People-Technology triad

Software Development Process

Modeling a Software System UML: Unified Modeling Language Design Activities with UML

Project goalBusiness goal

Analysis

Design Implementation

Maintenance

TestRequirement Analysis Technique

Software Architecture/Design Technique

Programming Technique

TestingTechnique

Maintenance related Technique

Telelogic Tau TTCN Suite

Telelogic Tau SDL Suite,IBM Rational Rose RT

Telelogic Tau Logiscope,Doxygen, etc.

Designer

Programmer

Tester

Analyst

Telelogic TauIBM Rational Rose

“While process is often described as a leg of the process-people-technology triad, it may also be considered the “glue” that unifies the other aspects.”

Process

Process

Technology

People

TechnologyPeople

Process

8/53

Here, We Focus on...


Code

Maintenance Test

Programming Technique

Eclipse, Jbuilder etc.

Programmer

SW Development

Process

Process

Technology

People

Conceptualization

Software Configuration

Management

Software Requirement

Management

TelelogicDOORS

Requirement Elicitation Technique

AnalystDesignAnalysis

Requirement Analysis Technique

Analyst

Software Architecture/Design Technique

Telelogic Tau G2 DesignerWe needanalysis capabilities

We needdesign skills

9/53

For Analysis and Design of Software,


We use a ‘MODEL’

to analyze requirements,to design/illustrate software architectures,

to represent software behaviors,and so on.

10/53

What is a model? A model is a simplification of reality

Model


Reality ModelModeling

Implementation

Softwaresystem

Requirementsmodels

Analysis/designmodels

11/53

What is a model? A model is an intended simplification of reality

Models (i.e. specifications) describe structures and behaviors of a system they intend to model.

Model


Modeling is a proven and well-accepted engineering technique(e.g., Architectural model of houses and buildings, Mathematical models)


Implementation

Softwaresystem

Requirementsmodels


12/53

What is a model? A model is a simplification of reality A model is the abstracted representation of requirements

Model (in Detail)



Implementation

Softwaresystem

Requirementsmodels


Requirements

If the software system is not yet developed...

We have to start here.

13/53

Examples*

Example Models in Real World


*http://www.ursalhomes.com/briana-single-house-and-lot-for-sale-cavite/ 14/53

Examples*


*http://www.godesignsolutions.com.au/services/architectural_design_drawings


15/53

Examples: Maps as abstractions


http://www.cs.toronto.edu/~sme/CSC302/notes/02-03-IntroModeling.pdf


16/53

http://www.cs.toronto.edu/~sme/CSC302/notes/02-03-IntroModeling.pdf

We model something To easily communicate information between different

stakeholders in an unambiguous way

Why Do We Use a Model?


17/53

We model something To deal with problem complexity

ABSTRACTION: Ignore detail to see the big picture**Every abstraction involves choice over what is important

DECOMPOSITION: Partition a problem into independent piecesPROJECTION: Separate different concerns (views) and describe

them separatelyMODULARIZATION: Choose structures that are stable over time, to

localize change



18/53

Waterfall Model for software development*



*http://pehop.com/waterfall-system-development-life-cycle/

RequirementSpecifications

System andSoftware Design

Implementation and Unit Testing

Integration andSystem Testing

Operationand Maintenance

Design system/software models• To adequately represent/specify stakeholders’ and

system requirements• To systematically implement a software based on

the developed models

19/53

We model something To specify target-language-independent designs To provide structure for problem solving To provide mechanisms (abstractions, views, filtering, structure) to

manage complexity To be able to easily experiment to explore multiple solutions

To reveal key design decisionsTo uncover problems and figure out what questions to ask

The exercise of modeling is more important than the model itself. Time spent perfecting the models might be time wasted…



20/53

Correct Every statement is one that the software shall meet

Unambiguous It has only one interpretation

Complete It includes all the requirements

Consistent No subset has conflict

Typical Properties of Good Models


Unambiguity is the fundamental property of models

21/53

Definition A modeling language is any language with which a model can be

described.An ML can be anything that helps you describe your system

(e.g., pseudo-code, actual code, pictures, diagrams, or description)An ML contains two elements:

Notation is the elements that make up a modeling language

Semantics are the descriptions of what the notation means

Modeling Language (ML)


22/53

Visual notation like UML can be a solution!

What Can Be an Effective ML?


23/53

UMLUnified Modeling Language


“Method Wars” of object-oriented paradigm in 1990s OOAD, OMT, OOSE, Fusion, OOA/OOD Each of the methods had its own notation, process, and tools

History of UML


They needed to be unified in a refined & easy-to-understand modeling method

25/53

Unified Modeling Language (UML)


Unified End to many similar approaches Standardized by OMG

Unified Modeling Language

26/53




Modeling Main (creative) process of software development


27/53




Modeling Main (creative) process of software development

Language Provides notation, no method, no process Graphical, collection of different diagram types


28/53

Visual modeling language for specifying, constructing and documenting Object-oriented modeling Model/view paradigm Target language independent


http://www.uml.org


29/53

http://www.uml.org/

UML 2.0 leverages the industry’s investment in UML 1.x and makes UML comprehensive, scalable and mature UML 2.0 designed to solve the key UML 1.x issues Major improvements in UML 2.0 include:

New internal structure diagrams support precise definition of architecture, interfaces and components

Improved scalability in state machine and sequence diagramsBetter semantic foundation enables advanced model verification and

full code generation

UML 2.0


30/53

UML is used to describe software-intensive system in terms of object-oriented paradigm

Use of UML


Types of Systems Common characteristics

Informationsystems

store, retrieve, transform, and present information to user

Technicalsystems

handle and control technical equipment such as telecommunications, military systems, or industrial processoften real-time system

Embeddedsystems

execute on simple hardware embedded in some other equipment such as mobile phone, car, household appliance

Distributedsystems

distributed on a number of machinesoften built on object mechanism such as CORBA, DCOM, Java Beans/RMI

31/53


Each diagram is just a view of part of the system

Together, all diagrams provides a complete picture

Diagram/View Paradigm

Underlying System Model

32/53

(Recap) The UML is a visual modeling language used to describe the model of software system Structure: What are software’s features? Behavior: What constitutes the software and how do they interact?

Describe a Software System with UML


33/53

UML Diagrams


Class Diagram

ComponentDiagram

CommunicationDiagram

Interaction OverviewDiagram

Sequence Diagram

TimingDiagram

Use CaseDiagram

State MachineDiagram

ActivityDiagram

PackageDiagramComposite

StructureDiagram

ObjectDiagram

DeploymentDiagram

Interaction Diagram

BehavioralDiagram

StructuralDiagram

Each diagram is just a view of part of the system

34/53

UML Diagrams


Class Diagram

ComponentDiagram



Sequence Diagram

TimingDiagram

Use CaseDiagram


ActivityDiagram


StructureDiagram

ObjectDiagram

DeploymentDiagram

Interaction Diagram

BehavioralDiagram

StructuralDiagram

35/53

UML 2.x Diagrams

http://stackoverflow.com/questions/7779614/how-to-represent-a-loop-in-a-class-diagram


36/53

UML 2.x Diagrams (Extended)

http://www.uml-diagrams.org/uml-25-diagrams.html


37/53

Design Activities with UML


Software Modeling

Software Development

Modeling Implementation

Requirementspecification

Analysis Design Implementation

Requirementsmodel(s)

Analysismodel(s)

Designmodel(s)

System


39/53

Software Modeling with UML (1/2)

Software Development

Modeling Implementation

Requirementspecification

Analysis Design Implementation

Software Maintenance

Verification &Validation

Testing

UML


40/53

Diagrams used for each development phase

Software Modeling with UML (2/2)


Requirementdefinition

Analysis DesignImplemen-

tationTesting

Package diagram

Use-casediagram

Class diagramObject diagram

State machine diagramActivity diagram

Interaction diagram

Component diagramComposite structure

diagramDeployment diagram

41/53

Software Development Process


Requirement AnalysisArchitectural

DesignDetailedDesign

Implemen-tation

Testing

RequirementAnalysis

ClassSubsystem/Component

DesignClass

SourceCode

TestCases

Use-caseSpec.

SupplementarySpec.

class…

class…

class…class…

expressed interms of

structured by realized byimplemented

byverified/

validated by

42/53

UML supports various types of systems

UML supports object-oriented (OO) & component-based development (CBD) development methodology

UML: Generality


Real-time system

Distributed system

State-machine, Sequence, Timing diagram(s)

Deployment diagram(s)

OO

CBD

Use-case, Class, Interaction diagram(s)

Component, Composite structure diagram(s)

43/53

UML Diagrams – (1) Structural Diagrams

*http://www.uml-diagrams.org/uml-25-diagrams.html


Diagram Description Elements

Classdiagram

Shows structure of the designed system, subsystem or component as related classes and interfaces, with their features, constraints and relationships

Class, interface, feature, constraint, relationships

Objectdiagram

Shows instance specifications of classes and interfaces (objects), slots with value specifications, and links(i.e., a class diagram with objects and no classes)

Instance specification, object, slot, link

Packagediagram

Shows packages and relationships between the packagesPackage, element, dependency, element/ package import & merge

Componentdiagram

Shows components and dependencies between them.- Used for Component-Based Development (CBD)- Used to describe systems with Service-Oriented

Architecture (SOA)

Component, interface, provided & required interface, class, port, connector, artifact, etc.

Composite structurediagram

Show (a) internal structure of a classifier, (b) a behavior of a collaboration

Deploymentdiagram

Show architecture of the system as deployment ofsoftware artifacts to deployment targets

Deployment, artifact, deployment target, node, device, execution, environment, communication path, deployment spec

44/53

UML Diagrams – (2) Behavioral Diagrams

*http://www.uml-diagrams.org/uml-25-diagrams.html


Diagram Description Elements

Use-case diagram

Describe a set of actions (use cases) that some system or systems should or can perform in collaboration with one or more external users of the systems (actors) to provide some observable and valuable results to the actors or other stakeholders of the system

Use case, actor, subject, extend, include, association

State machine diagram

Used for modeling discrete behavior through finite state transitions and expressing the behavior of a part of the system

State, transition, pseudostate

Activity diagramShows sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors(e.g., control flow and object flow models)

Activity, partition, action, object, control, activity edge

Sequence diagram Most common kind of interaction diagrams which focuses on the message interchange between lifelines (objects)

Lifeline, execution, specification, message, combined fragment, interaction use, state invariant, destruction occurence

Communication diagram, Interaction overview diagram, Timing diagram

*See Note.

45/53

Final Products to Be Produced


Analysis Design

Use-casemodel

Domainmodel

Sequence model

Classdiagram

State machinediagram

Composite structure(Signal, Interface etc.)

Generated Code

Refinement

46/53

We will study three types of UML diagrams:

In This Lecture,


Class Diagram

ComponentDiagram



Sequence Diagram

TimingDiagram

Use CaseDiagram


ActivityDiagram


StructureDiagram

ObjectDiagram

DeploymentDiagram

Interaction Diagram

BehavioralDiagram

StructuralDiagram

47/53

We will study three types of UML diagrams: Use-case diagram

A high level visualization of how the system worksBuilt on requirement specifications from discussions with developers,

customers, and/or end users

Class diagramA collection of static model elements such as classes and types, their

contents, and their relationships

Sequence diagramModel of sequential logic, in effect the time ordering of messages

between classifiers

In This Lecture,


48/53

We will study modeling notations of the diagrams:

In This Lecture,


49/53

We will design a software system Specify the structure of how a software system will be written and

function, without actually writing the complete implementation

A transition from “what” the system must do, to “how” the system will do it What classes will we need to implement a system that meets our

requirements? What fields and methods will each class have? How will the classes interact with each other?

In This Lecture,


https://courses.cs.washington.edu/courses/cse403/11sp/lectures/lecture08-uml1.pdf 50/53

We have to know following concepts (terms): Stakeholder(s)? Requirement(s)? Use case(s)? Actor(s)? Class, Object, and Instance?

The instances of a class are called objects.

State(s) of Software? Association(s)?

Before Studying Modeling of Diagrams,


51/53

Activities (QUIZ)


QUIZ

Who can be stakeholders of a software system?

What is a software requirement?

What are the possible requirements of <Social Gallery> app? Functional requirements Non-functional requirements

53/53

Thank You.

2017-Spring. CS350 Introduction to Software EngineeringUML Overview [1/2]

Young-Min Baek

UML Overview [1/2] - KAIST

Documents