What is UML? What is UP? [Arlow and Neustadt, 2005] January 23, 2014 CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of.

What is UML?What is UP?

[Arlow and Neustadt, 2005]

January 23, 2014

CS 426 Senior Projects in Computer Science

University of Nevada, RenoDepartment of Computer Science & Engineering

2/32

Outline.

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

.Outline

What is UP? UP History UP Axioms UP Core Workflows UP Structure Details on UP Phases

4/32

What is UML?

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

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

6/32

MDA – the future of UML

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

7/32

UML: Why “unified”?

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

Objects and UML

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

UML Structure

There are three main parts in UML structure, as indicated below, Fig. 1.4 [Arlow & Neustadt 2005]

10/32

UML Building Blocks 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 Building Blocks: Things

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 Building Blocks: Relationships 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

UML Building Blocks: Diagrams..

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

UML Building Blocks: .Diagrams.Types of UML diagrams [Fig. 1.6, Arlow & Neustadt, 2005]

15/32

UML Building Blocks: ..DiagramsUML syntax for diagram [Fig. 1.7, Arlow & Neustadt, 2005] &diagram with implied frame [Fig. 1.8, Arlow & Neustadt, 2005]

16/32

UML Common Mechanisms UML has four common mechanisms that are applied consistently,

in different contexts, throughout UML [Fig. 1.9, Arlow 2005]

17/32

UML Common Mechanisms: Specifications Specifications are textual descriptions of the semantics of UML

elements. Example, Fig. 1.10 [Arlow & Neustadt, 2005]

18/32

UML Common Mechanisms: Adornments Adornments allow showing more information on UML elements.

Example, Fig. 1.11 [Arlow & Neustadt, 2005]

19/32

UML Common Mechanisms: Common Divisions

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

UML Common Mechanisms: Extensibility

There are three types of mechanisms that provide supportfor UML extensibility, Table 1.3 [Arlow & Neustadt, 2005]

21/32

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

.ArchitectureThe “4 +1 views” architecture, Fig. 1.13 [Arlow & Neustadt 2005]

23/32

What is UP?

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 HistoryUP evolution, Fig. 2.3 [Arlow & Neustadt, 2005]

25/32

UP Founders

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

UP Axioms

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

UP Core Workflows.

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 completeversion of the final system. An iteration is the differencebetween two consecutive baselines.

28/32

.UP Core WorkflowsFig.2.5 [Arlow & Neustadt, 2005]

29/32

UP Structure.Fig.2.6 [Arlow & Neustadt, 2005]

30/32

.UP Structure

Fig.2.7 [Arlow & Neustadt, 2005]

31/32

UP: Details on Phases.

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

UP: .Details on Phases

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]