Fit2005 Lecture1 Main 4pp

7/31/2019 Fit2005 Lecture1 Main 4pp

1/15

www.monash.edu.au

FIT2005 System Analysis, Design & Architecture

Module 1:

Introducing UML and UP

2

COMMONWEALTH OF AUSTRALIA

Copyright Regulations 1969WARNING

This material has been reproduced and communicated toyou by or on behalf of Monash University pursuant to Part

VB of the Copyright Act 1968(the Act).

The material in this communication may be subject tocopyright under the Act. Any further reproduction or

communication of this material by you may be the subject ofcopyright protection under the Act.

Do not remove this notice.

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

Module 1 Objectives (continued)

On completion of this module you should be able to:

Explain the role of using a visual language in systemsdevelopment

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.


2/15

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, anenvironment, inputs, outputs, a control mechanism and

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

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

Purpose of an Information System

The main purpose of an informationsystem is to maintainand deliver information.

Should be able to inform decision makers at all levels ofan organisation of the state variables which represent thecurrent state of the organisation.

State variables any quantity or piece of informationwhich can be used to describe the current status of the

organisation

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


3/15

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

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

Who creates new software systems?

In-house Development software developed by staffinside the organisation

Outsourced Development software is developed byan external organisation

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, whofollow defined methodologies to produce software forclients:

Analysts/Designers

Programmers

HCI-specialists

Graphic Artists

And other roles


4/15

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

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 tographically present the design of a software systemsparts.

UP uses UML As the way to document the work performed

www.monash.edu.au


UML An Introduction

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


5/15

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

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

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

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)


6/15

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

UML Structure

UML consists of:

Building blocks

Common Mechanisms

Architecture

23

UML Structure (5)

UML has 4 Common Mechanisms:

Specifications

textual descriptions of the features and semantics of model

elements

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

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 onexisting 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}


7/15

25

UML Structure

UML consists of:

Building blocks

Common Mechanisms

Architecture

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

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

www.monash.edu.au


The Unified ProcessAn Overview

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, quantifiableapproach to the development, operation, andmaintenance of software(IEEE Standard 610.12-1999)

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


8/15

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

UP Axioms

UP has three basic axioms

Requirements and risk driven

Architecture-centric

Iterative and incremental

31

Iterative and Incremental

Humans find problem solving better when the problemsare small

Break a large problem into smaller problems and solve

each 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

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.


9/15

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 theworkflows

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

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

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

An Activity is a tangible unit of work performed by aworker

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 element

or a document.

36

UP: Overview of Activities for Workers in each workflow

Source: [Jacobson 1] Figure 12.3


10/15

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

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

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 final

system

Milestone: Software system finished, ready for beta testing

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; correctproblems uncovered in testing

Test beta testing, acceptance testing (at user site)

Goals: Correct defects

Prepare user sites for the software; tailor software to operate at

the user site Conduct a post-project review

Milestone: Product Release


11/15

41

The Requirements Workflow

Purpose/Goals [Kruchten, ch 9]:

To discover and reach agreement with customers andother 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

42

Activities of the Requirements Workflow (1)

Source: Arlow

43

Activities of the Requirements Workflow (2)

44

Requirements Workflow

Key Artifacts produced:

Use Case Model (contains Use Cases, and Actors)

Requirements List

Glossary defines key terms for the project


12/15

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

46

Analysis Workflow - Activities

Source: Jacobson

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 classesand packages; gives structure to theinternal view

Used primarily as a contractbetween the customer and thedevelopers on what the system

should and should not do

Used primarily by developers tounderstand how the system shouldbe shaped, i.e. designed and

implemented

Source: Jacobson: Table 8.1Continued

48

Comparing Use Case and Analysis Models (2)

Use Case Model Analysis Model

May contain redundancies,inconsistencies, etc. among

requirements

Should not contain redundancies,inconsistencies, etc. among

requirementsCaptures the functionality of thesystem, including architecturallysignificant functionality

Outlines how to realize thefunctionality within the system,including architecturally significantfunctionality; works as a first cut atdesign

Defines use cases that are furtheranalysed in the analysis model

Defines use-case realizations, eachone representing the analysis of ause case from the use-case model

Source: Jacobson: Table 8.1


13/15

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, theDesign Model focuses on howthis functionality will beimplemented

Key activities:

Architectural Design

Design a use case

Design a class Design a subsystem

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

51

Design Workflow - Activities

Source: Jacobson52

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

Source: Jacobson: Table 9.1


14/15

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.

Source: Jacobson: Table 9.1 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 comprisethe software of the system.

Along the way perform unit tests

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

55

Implementation Workflow - Activities

Source: Jacobson 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.


15/15

57

Test Workflow - Activities

58

Homework

Work through Module 1 of the Study Guide

Read relevant parts from Arlow Chapters 1 and 2and Kruchten (on the Librarys web site)

Read through the assignment tasks and case study whenthey become available

Beforethe next lecture session, read through Module 2 ofthe study guide, and the specified readings from Arlowand from Armour (on the Librarys web site)

Fit2005 Lecture1 Main 4pp

Documents

Transcript of Fit2005 Lecture1 Main 4pp