fit2005 lecture1 main big

7/31/2019 Fit2005 Lecture1 Main Big

1/58

www.monash.edu.au

FIT2005 System Analysis, Design & Architecture

Module 1:

Introducing UML and UP


2/58

2

COMMONWEALTH OF AUSTRALIA

Copyright Regulations 1969

WARNING

This material has been reproduced and communicated to

you by or on behalf of Monash University pursuant to PartVB of the Copyright Act 1968(the Act).

The material in this communication may be subject to

copyright under the Act. Any further reproduction orcommunication of this material by you may be the subject ofcopyright protection under the Act.

Do not remove this notice.


3/58

3

Module 1 Objectives

On completion of this session you should have a basic conceptualunderstanding of:

The structure of the Unified Modelling Language.

UMLs building blocks as being composed of things, relationships,and diagrams;

UMLs four common mechanism: specifications, adornments,

common divisions and extensibility mechanisms; Five ways by which to look at the architecture of a system: logical,

process, implementation, deployment and use case views.

The axioms of the Unified Process

The five core workflows of the Unified Process: requirements,analysis, design, implementation, and testing.

The four phases of the Unified Process: inception, elaboration,construction, transition.


4/58

4

Module 1 Objectives (continued)

On completion of this module you should be able to:

Explain the role of using a visual language in systems

development

Explain the role of a software engineering process insystems development;

Describe the relative emphasis of certain workflows indifferent phases of the unified process;

Describe the goals of each phase of the Unified Process;

Describe the focus of each phase of the Unified Process;

List conditions of satisfaction of each phase of the UnifiedProcess.

Describe the activities involved in each Workflow of UP.


5/58

5

Revision of Concepts (from FIT2001)

(Raw) Data unprocessed facts

Information the outcome of organising raw data intomeaningful contexts

Knowledge Information that is integrated into complexstructures

System a complex interacting set of elements, forwhich it is possible to identify a boundary, an

environment, inputs, outputs, a control mechanism and

some process of transformation that the system achieves(Bennet 2002)


6/58

6

Terminology

Information SystemA System which assembles,stores, processes and delivers information relevant to an

organisation (or to society), in such a way that theinformation is accessible and useful to those who wish touse it, including managers, staff, clients and citizens. Aninformation system is a human activity (social) systemwhich may or may not involve the use of computersystems.(British Computer Society)

In this unit, we assume the use of computer systems.Also we will deal with software systems in general(not only information systems)


7/58


8/58

8

Who uses software systems

Organisation a formal collection of people and otherresources established to accomplish a set of goals

(Satir 2003) for profit or not-for-profit.

Some software systems intended for Private Persons


9/58

9

When is a software system acquired?

Three key reasons (Oz 2004):

An opportunity

A current problem

A directive

it is the responsibility of the information systems manageror chief information officer (CIO) within the organisation to

decide whether a new software system is needed.


10/58

10

Where do software systems come from?

Pre-packaged software a product which can bebought and used straight away (without modifications)

Systems Development a new software product isdeveloped from scratch or by integrating pre-builtcomponents


11/58

11

Who creates new software systems?

In-house Development software developed by staffinside the organisation

Outsourced Development software is developed byan external organisation


12/58

12

Roles

Client The organisation/person requiring the system

Vendor The organisation/person which provides thesystem

A systems development organisation employs ITprofessionals with a range of skills and experience, who

follow defined methodologies to produce software forclients:

Analysts/Designers

Programmers HCI-specialists

Graphic Artists

And other roles


13/58

13

Software Systems Development

Two perspectives:

The Product The system that is to be developed,the outcome of the process

The Process the decisions and steps involved indeveloping the system

A Quality Product is one which satisfies the clientsrequirements

A Quality Process is a process which allows the productto be developed on time, within budget, and which is easyto work with, understand and maintain. (Burch 1992)


14/58

14

Unified Process and Unified Modeling Language

The Unified Process (UP) is one process which anorganisation could choose to adopt as their methodology

for software development.

The Unified Modeling Language (UML) is a way to

graphically present the design of a software systemsparts.

UP uses UML As the way to document the work performed


15/58

www.monash.edu.au


UML An Introduction


16/58

16

UML A Visual Language

UML is a general purpose visual language

UMLs purpose is to modelaspects of software systems

All languages have common elements:

Syntax rules for forming valid sentences, expressions of ideas. Semantics the meaning of the expressed idea

Examples (using textual language: English)

Cat mat sat the on

The mat sat on the cat

The cat sat on the mat

Invalid Syntax

Valid Syntax

Valid Syntax

Unclear semantics

Clear semantics

Unclear semantics


17/58

17

UML Structure

UML consists of:

Building blocks

Common Mechanisms Architecture

There are just 3 Building Blocks: Things the elements used to express ideas in models you make

Relationships these tie the things together. Gives meanings tothings

Diagrams present a facet of the model of the system


18/58

18

Model vs Diagrams

Model the things and relationships

Diagram presents a partial view of the model

Some thing can be in the model but might not be in any diagram(particularly when using a tool to make models)

Some thing in a diagram mustbe in the model!

Some thing from the model may be presented from multiple,different perspectives in different diagrams


19/58

19

UML Structure (2)

Types of things:

Structural things nouns

The subjects of the model, such as classes, use cases,collaborations

Behavioral things verbs

Interactions, activities, states

Grouping things

Mechanisms for grouping semantically related things as a unit

Annotational things Mechanism for writing notes using plain natural language.


20/58

20

UML Structure (3)

Relationships how two or more things relate to each other

Association a relationship between peer elements

Dependency one thing may be affected by changes tothe other

Containment inverse of grouping Realization more complete manifestation of something.

Others (See page 13 of Arlow)


21/58

21

UML Structure (4)

Diagrams

UML defines 13 different types of diagrams

Class

Component

Deployment

Object Package

Sequence

Communication

We will learn the details of most of these through the unit

Activity

Use Case

State Machine

Timing Composite Structure

Interaction Overview


22/58

22

UML Structure

UML consists of:

Building blocks



23/58

23

UML Structure (5)

UML has 4 Common Mechanisms:

Specifications

textual descriptions of the features and semantics of modelelements

The meat of the model: the semantic backplane

Adornments Items of information which can be exposed on a model element

Common Divisions

Ways of thinking about the world Classifier/Instance

Interface/Implementation


24/58

24

UML Structure (6)

UML has 4 Common Mechanisms:

Extensibility Mechanisms

Constraints

Specifies some condition or rule about the modeling element thatmust remain true.

Represented as text inside braces, e.g. {unique}

Stereotypes Allow you to invent new types of modeling elements based on

existing elements YOU decide its semantics.

Usually represented by a name/description inside guillemets,

e.g. sql-query Tagged values

Properties associated with model elements: name-value pair

E.g. {language = Java} {author = Ken Smith}


25/58

25

UML Structure

UML consists of:

Building blocks


Architecture refers to the (high-level) structure of thesystem

What parts has it been decomposed into

How the parts are connected

How the parts interact

What guiding principles inform the design of the system


26/58

26

The 4+1 View of Architecture

One common way of viewing architecture is the 4 +1different views of the system

Logical view system functionality and vocabulary

Process view

system performance, scalability and vocabulary

Implementation view how system is assembled and configured

Deployment view

models the physical deployment of the system

Use Case view (the +1)

Captures the basic requirements for the system

Provides the basis for construction of the other views


27/58

www.monash.edu.au


The Unified Process

An Overview


28/58

28

Software Engineering

Software Engineering is the task of designing a softwaresystem

Compare to other Engineering, e.g. Civil Engineering

IEEE definition:

The application of a systematic, disciplined, quantifiable

approach to the development, operation, andmaintenance of software(IEEE Standard 610.12-1999)

In order to perform the task, you need to follow some

process


29/58

29

Unified Process

The Unified Processis a software engineering process

Originated with the inventors of UML

A commercial version exists called Rational Unified Process

The UP models the who, when and what of the systemdevelopment process

Its main purpose is to provide guidanceabout how you wouldconceive of the process of software development

Key elements:

Workers

Activities

Artifacts

Workflows


30/58

30

UP Axioms

UP has three basic axioms

Requirements and risk driven

Architecture-centric

Iterative and incremental


31/58

31

Iterative and Incremental

Humans find problem solving better when the problemsare small

Break a large problem into smaller problems and solveeach of the smaller problems

Refine the solution to improve it.

In UP, each iterationcontains all of the elements of asoftware development project following the moretraditional waterfall approach, i.e.: Planning

Analysis and design Construction

Integration and test

Release


32/58

32

Iteration Workflows

A workflowis a set of activities, performed by workers insome order, to use or produce artifacts or outcomes

There are 5 core workflows in UP: Requirements

Analysis

Design

Implementation Test

Each iteration involves the 5 core workflows to someextent.

Result of an iteration is called a baseline. The difference between it and the previous baseline is an

increment.


33/58

33

The Structure of UP

UP divides the software development life cycle into fourphases

Each phase ends with a major milestone. Inception Life cycle objectives

Elaboration Life Cycle Architecture

Construction Initial Operational Capability Transition Product Release

Each phase can have multiple iterations through the

workflows

The exact number of iterations can differ for each phaseand for different software development projects


34/58

34

Example Project Lifecycle using UP

Shows the relative amount of effort spent in different workflows (down left side),at different phases of the project.


35/58

35

Workers, Activities, Artifacts

A Worker is a person who for a period of time will havespecific responsibilities

It is a role Person 1 could perform multiple roles at different times

Multiple people could perform same role at different times

AnActivity

is a tangible unit of work performed by a

worker

An Artifact is a tangible piece of information that iscreated, changed and used by workers when performingactivities An artifact can be a model, a model elementor a document.


36/58

36

UP: Overview of Activities for Workers in each workflow

Source: [Jacobson 1] Figure 12.3


37/58

37

Inception Phase

Focus is on requirements and analysis workflows

Goals are:

Establish feasibility

Create a business case to demonstrate project will deliverbusiness benefits

Capture essential requirements

Identify critical risks

Milestone:

Lifecycle objectives

See textbook Table 2.1

[Quantifiable]

To help scope the system


38/58

38

Elaboration Phase

The Focus in each workflow is as follows:

Requirements refine the system scope and requirements

Analysis Establish what to build Design create a stable architecture

Implementation build the architectural baseline

Test - test the architectural baseline

Goals:

Create an executable architectural baseline

Refine the risk assessment

Define quality attributes (non-functional requirements) Capture use case for ~80% of the functional requirements

Milestone: Life Cycle Architecture


39/58

39

Construction Phase

Focus: mainly implementation workflow

Focus for each workflow:

Requirements uncover any requirements that had been missed

Analysis finish the analysis model

Design finish the design model

Implementation build the initial operational capability

Test test the initial operational capability

Goals

To complete all requirements, analysis and design

To evolve the architectural baseline (from Elaboration) into the finalsystem

Milestone: Software system finished, ready for beta testing


40/58

40

Transition Phase

Mainly implementation and test workflows

Focus:

Requirements not applicable Analysis not applicable

Design modify the design if problems arise in beta testing

Implementation tailor the software for the users site; correct

problems uncovered in testing Test beta testing, acceptance testing (at user site)

Goals: Correct defects

Prepare user sites for the software; tailor software to operate atthe user site

Conduct a post-project review

Milestone: Product Release

Th R i W kfl


41/58

41

The Requirements Workflow

Purpose/Goals [Kruchten, ch 9]:

To discover and reach agreement with customers and

other stakeholders on what the system should do Eliciting and prioritizing requirements from stakeholders

Process of negotiation: balancing conflicting interests/desires

To provide system developers with better understandingof the system requirements

To define the boundaries of the system

To provide a basis for planning the technical content ofiterations

To provide a basis for estimating cost/time to develop

A ti iti f th R i t W kfl (1)


42/58

42

Activities of the Requirements Workflow (1)

Source: Arlow

A ti iti f th R i t W kfl (2)


43/58

43

Activities of the Requirements Workflow (2)

R i t W kfl


44/58

44

Requirements Workflow

Key Artifacts produced:

Use Case Model (contains Use Cases, and Actors)

Requirements List Glossary defines key terms for the project

Analysis Workflow overview


45/58

45

Analysis Workflow - overview

The aim of Analysis is to produce an analysis model

Focuses on whatthe system needs to do

2 main Artifactsproduced by Analysis: Analysis classes - model key concepts in the business domain.

Use case realizations

Key Activitiesperformed for Analysis Workflow: Architectural Analysis

Analyse a use case

Analyse a class

Analyse a package

Analysis Workflow Activities


46/58

46

Analysis Workflow - Activities

Source: Jacobson

Comparing Use Case and Analysis Models


47/58

47

Comparing Use Case and Analysis Models

Use Case Model Analysis Model

Described using the language ofthe customer/client organisation

Described using the language of thedevelopers

External view of the system Internal view of the system

Structured by use cases;

gives structure to the externalview

Structured by stereotypical classes

and packages; gives structure to theinternal view

Used primarily as a contract

between the customer and thedevelopers on what the systemshould and should not do

Used primarily by developers to

understand how the system shouldbe shaped, i.e. designed andimplemented

Source: Jacobson: Table 8.1Continued

Comparing Use Case and Analysis Models (2)


48/58

48

Comparing Use Case and Analysis Models (2)

Use Case Model Analysis Model

May contain redundancies,

inconsistencies, etc. amongrequirements

Should not contain redundancies,

inconsistencies, etc. amongrequirements

Captures the functionality of thesystem, including architecturally

significant functionality

Outlines how to realize thefunctionality within the system,

including architecturally significantfunctionality; works as a first cut atdesign

Defines use cases that are further

analysed in the analysis model

Defines use-case realizations, each

one representing the analysis of ause case from the use-case model

Source: Jacobson: Table 8.1

Design Workflow Overview


49/58

49

Design Workflow - Overview

The focus of work late in elaboration phase, and early inconstruction phase

Aims to produce the design model Whereas Analysis focuses on whatthe system needs to do, the

Design Model focuses on howthis functionality will beimplemented

Key activities:

Architectural Design

Design a use case

Design a class Design a subsystem

Artifacts of Design Models


50/58

50

Artifacts of Design Models

A Design Model consists of:

Subsystems

Design classes

Interfaces

Use Case Realisations Design Deployment Diagrams

Architectural Description

Often the analysis model evolves intothe design model

Design Workflow - Activities


51/58

51

Design Workflow - Activities

Source: Jacobson

Comparing Analysis and Design models


52/58

52

Comparing Analysis and Design models

Analysis Model Design Model

Conceptual model, because itis an abstraction of the systemand avoids implementationissues

Physical model, because it is ablueprint of the implementation

Design-generic (applicable toseveral potential designs)

Not generic, but specific for animplementation

Three (conceptual) stereotypeson classes: control, entity,and boundary

Any number of (physical)stereotypes on classes,depending on implementationlanguage


Comparing Analysis and Design models (2)


53/58

53

Comparing Analysis and Design models (2)

Analysis Model Design Model

Outlines the design of thesystem, including itsarchitecture

Manifests the design of thesystem, including its architecture

Defines a structure that is anessential input to shaping thesystem including creating thedesign model

Shapes the system while tryingto preserve the structure definedby the analysis model as muchas possible.


Implementation Workflow - Overview


54/58

54

Implementation Workflow Overview

The implementation workflow is the main focus of theconstruction phase

The purposes of the implementation workflow include: Code the classes, components and subsystems, which comprise

the software of the system.

Along the way perform unit tests

Distribute the system functionality by placing executablecomponents onto particular hardware devices.

Implementation Workflow - Activities


55/58

55

Implementation Workflow Activities

Source: Jacobson

Test Workflow - Overview


56/58

56

Test Workflow Overview

Testing involves verifying that the implementationmatches the requirements.

The purposes of the test workflow include: Finding and documenting failures in the software product: e.g.

defects and problems.

Advising management on the perceived quality of the software

Validating that the software works as designed, and that therequirements are implemented appropriately.

Test Workflow - Activities


57/58

57

Homework


58/58

58

Work through Module 1 of the Study Guide

Read relevant parts from Arlow Chapters 1 and 2

and Kruchten (on the Librarys web site)

Read through the assignment tasks and case study when

they become available

Beforethe next lecture session, read through Module 2 ofthe study guide, and the specified readings from Arlow

and from Armour (on the Librarys web site)

fit2005 lecture1 main big

Documents