CS 426 Senior Projects in Computer Science

What is UML?

What is UP?


[
Arlow

and
N
eustadt
, 2005]


January 24, 2013

CS
426 Senior Projects in
Computer Science

University of Nevada, Reno

Department of Computer Science & Engineering

2
/32


What is UML?


UML history


MDA
–

the future of UML


Why
“
unified
”
?


Objects and UML


UML structure


UML building blocks


UML common mechanisms


Architecture

3
/32


What is UP?


UP History


UP Axioms


UP Core Workflows


UP Structure


Details on UP Phases


4/32


The UML (
Unified Modeling Language
) is a general
purpose visual modeling language for systems


Usually associated with OO software systems, but with wider
application than that


Incorporates modern best practices in modeling techniques and
software engineering


Designed to be supported by CASE tools


It is
not

a methodology, but a notation that can be used in various
software development methodologies


Not tied to any methodology or specific

lifecycle; however the
preferred method

for using UML is the UP (
Unified Process
)

5
/32

Stages of UML evolution, Fig. 1.2 [Arlow & Neustadt, 2005]




6/32


Model driven architecture (MDA) is based on the idea that
models can drive the production of executable software
environments


7
/32


UML unification encompasses the following:


Development lifecycle
:
UML can be used from requirements
engineering to implementation


Application domains
:
UML has been used in a profusion of
applications, of various types


Implementation languages and platforms
:
UML is language and
platform independent


Development processes
:
UP is only one of the processes
supported by UML


Its own internal concepts
:

UML is based on a set of concepts that
have been applied consistently throughout the notation’s
development


8
/32


The main premise for using UML is that software
systems can be modeled as
collections of
interacting objects


There are two major, complementary parts in a
UML model:


Static structure
= constituent objects + their
relationships


Dynamic behaviour
= functionality provided by the
collaborating objects


9
/32

There are three main parts in UML structure, as indicated

b
elow, Fig. 1.4 [
Arlow

&
Neustadt

2005]





10
/32


UML is composed of three building blocks [Fig. 1.5,
Arlow

2005]:


Things, or modeling elements (modeling constructs)


Relationships, that specify how things relate semantically


Diagrams, that provide views into UML models and show
collections of interrelated things



11
/32


UML
things
, or
modeling elements
, can be
classified as:


Structural things
, e.g., class, interface, use case, component,
node (the “nouns” of a UML model)


Behavioural things
, such as interactions and state machines (the
“verbs” of a UML model)


Grouping things
, e.g. package, which gathers related modeling
elements


Annotational

things
, e.g., the “sticky note” that can be
appended to any modeling construct

12
/32


UML

relationships
indicate how two or more things are
interconnected. Relationships apply to structural and grouping
things and are as follows [Table 1.1,
Arlow

&
Neustadt

2005]:



13
/32


A
UML model

is a repository of all
things

and
relationships
created
to describe the structure and behavior of the system under
development


Diagrams
provide views (or windows) into this model


Diagrams also provide mechanisms for entering information into
the model


There are 13 types of UML diagram, 6 of them describing the
static structure of the system (
the static model
), and 7 the
dynamic aspects of the system (
the dynamic model
)

[see next slide]



14/32

Types of UML diagrams [Fig. 1.6,
Arlow

&
Neustadt
, 2005]


15
/32

UML syntax for diagram [Fig. 1.7,
Arlow

&
Neustadt
, 2005] &

diagram with implied frame [Fig. 1.8,
Arlow

&
Neustadt
, 2005]


16
/32


UML has four common mechanisms that are applied consistently,
in different contexts, throughout UML [Fig. 1.9,
Arlow

2005]




17
/32


Specifications

are textual descriptions of the semantics of UML
elements. Example, Fig. 1.10 [
Arlow

&
Neustadt
, 2005]




18
/32


Adornments

allow showing more information on UML elements.
Example, Fig. 1.11 [
Arlow

&
Neustadt
, 2005]




19
/32


Common divisions

are ways of thinking about the world
(for modeling purposes)


Common divisions in UML are of two types:


Classifiers and instances [see Table 1.2 in the book]


Interface and implementation

20
/32

There are three types of mechanisms that provide
support

for UML
extensibility
, Table 1.3 [
Arlow

&
Neustadt
, 2005]




21
/32


The system architecture is
“
the organizational structure of the system,
including its decomposition into parts, their connectivity, interaction,
mechanisms and the guiding principles that inform the design of a system.
”

[
Rumbaugh

1998]


There is a typical
“
4+1 views
”

architecture of a system defined by UML:


Logical view
, captures the vocabulary of the problem domain using classes and
objects


Process view
, depicts the threads and processes of the system as active classes


Implementation view
,
shows the physical code base of the system in terms of
components


Deployment view
, models the physical deployment of components onto
computational nodes


Use case view
, captures the requirements of the system using a set of use cases. This
is the view
“
+1
”

to which all other views connect.



22
/32




The
“
4 +1 views
”

architecture, Fig. 1.13 [
Arlow

&
Neustadt

2005]

23
/32


A
software development
process

(SDP) or
software
engineering process
(SEP)
defines the
who
,
what
,
when
,
and
how

of developing
software


The
Unified Software
Development Process

(USDP)
or, in short, the
Unified Process

(UP) is an industry standard
process created by the authors
of UML

Fig 2.2 [Arlow & Neustadt 2005]

24
/32

UP evolution, Fig. 2.3 [
Arlow

&
Neustadt
, 2005]





25
/32


Grady Booch


Video: why engineering?


Video: the promise, the limits, the beauty of software


Video: smarter products for a smarter planet



Ivar Jacobson


Jim Rumbaugh

26
/32


Requirements and
risk driven


Architecture centric


Iterative and incremental


Each iteration contains all the elements of a regular software
development project: planning, analysis, design, construction,
integration, testing, internal or external release

27
/32


Requirements
:

Determining what the system should do


Analysis
:
Refining and structuring the requirements


Design
:
Defining system architecture to satisfy requirements


Implementation
:
Building the software


Testing
:
Verifying that the implementation is correct



A
baseline

is the result of an iteration, a partially
complete

version
of
the
final system. An
iteration

is the
difference

between two consecutive baselines
.



28
/32

Fig.2.5 [
Arlow

&
Neustadt
, 2005]

29
/32

Fig.2.6 [
Arlow

&
Neustadt
, 2005]

30
/32

Fig.2.7 [
Arlow

&
Neustadt
, 2005]

31
/32


Each of the four phases of UP (inception, elaboration,
construction, transition) has:


A goal


A focus of activity


One or more core workflows


A milestone, with a number of conditions of satisfaction


Details of the above for Inception are given next. The
remaining three phases are described in Subsection
2.9 of the textbook




32
/32


Inception


Goal: Get the project off the ground


Tasks:

▪
Assess feasibility

▪
Create a strong business case

▪
Capture essential requirements

▪
Identify critical tasks


Focus: Requirements specification and analysis


Milestone: Life
-
cycle objectives [see conditions of
satisfaction in Table 2.1 of the book]