You are on page 1of 58

FIT2005 System Analysis, Design & Architecture

Module 1: Introducing UML and UP

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 Part VB of the Copyright Act 1968 (the Act). The material in this communication may be subject to copyright under the Act. Any further reproduction or communication of this material by you may be the subject of copyright protection under the Act. Do not remove this notice.

Module 1 Objectives
On completion of this session you should have a basic conceptual understanding 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.

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 in systems development; Describe the relative emphasis of certain workflows in different 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 Unified Process. Describe the activities involved in each Workflow of UP.

Revision of Concepts (from FIT2001)

(Raw) Data unprocessed facts Information the outcome of organising raw data into meaningful contexts Knowledge Information that is integrated into complex structures System a complex interacting set of elements, for which 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)

Information System A System which assembles, stores, processes and delivers information relevant to an organisation (or to society), in such a way that the information is accessible and useful to those who wish to use it, including managers, staff, clients and citizens. An information system is a human activity (social) system which may or may not involve the use of computer systems. (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)

Purpose of an Information System

The main purpose of an information system is to maintain and deliver information.

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

State variables any quantity or piece of information which can be used to describe the current status of the organisation

Who uses software systems

Organisation a formal collection of people and other resources established to accomplish a set of goals (Satir 2003)
for profit or not-for-profit.

Some software systems intended for Private Persons

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 manager or chief information officer (CIO) within the organisation to decide whether a new software system is needed.

Where do software systems come from?

Pre-packaged software a product which can be bought and used straight away (without modifications) Systems Development a new software product is developed from scratch or by integrating pre-built components


Who creates new software systems?

In-house Development software developed by staff inside the organisation Outsourced Development software is developed by an external organisation


Client The organisation/person requiring the system Vendor The organisation/person which provides the system A systems development organisation employs IT professionals with a range of skills and experience, who follow defined methodologies to produce software for clients:
Analysts/Designers Programmers HCI-specialists Graphic Artists And other roles

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 in developing the system

A Quality Product is one which satisfies the clients requirements A Quality Process is a process which allows the product to be developed on time, within budget, and which is easy to work with, understand and maintain. (Burch 1992)

Unified Process and Unified Modeling Language

The Unified Process (UP) is one process which an organisation 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 systems parts. UP uses UML
As the way to document the work performed


FIT2005 System Analysis, Design & Architecture

UML An Introduction

UML A Visual Language

UML is a general purpose visual language UMLs purpose is to model aspects 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 Unclear semantics Clear semantics


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 to things Diagrams present a facet of the model of the system


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 must be in the model! Some thing from the model may be presented from multiple, different perspectives in different diagrams


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.


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 to the other Containment inverse of grouping Realization more complete manifestation of something. Others (See page 13 of Arlow)


UML Structure (4)

Diagrams UML defines 13 different types of diagrams
Class Component Deployment Object Package Sequence Communication Activity Use Case State Machine Timing Composite Structure Interaction Overview

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


UML Structure
UML consists of:
Building blocks Common Mechanisms Architecture


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

Items of information which can be exposed on a model element

Common Divisions
Ways of thinking about the world Classifier/Instance Interface/Implementation


UML Structure (6)

UML has 4 Common Mechanisms: Extensibility Mechanisms
Specifies some condition or rule about the modeling element that must remain true. Represented as text inside braces, e.g. {unique}

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}

UML Structure
UML consists of:
Building blocks Common Mechanisms Architecture

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

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


The 4+1 View of Architecture

One common way of viewing architecture is the 4 +1 different 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

FIT2005 System Analysis, Design & Architecture

The Unified Process An Overview

Software Engineering
Software Engineering is the task of designing a software system
Compare to other Engineering, e.g. Civil Engineering

IEEE definition: The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software
(IEEE Standard 610.12-1999)

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


Unified Process
The Unified Process is 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 system development process
Its main purpose is to provide guidance about how you would conceive of the process of software development

Key elements:
Workers Activities Artifacts Workflows

UP Axioms
UP has three basic axioms Requirements and risk driven Architecture-centric Iterative and incremental


Iterative and Incremental

Humans find problem solving better when the problems are small Break a large problem into smaller problems and solve each of the smaller problems Refine the solution to improve it. In UP, each iteration contains all of the elements of a software development project following the more traditional waterfall approach, i.e.:
Planning Analysis and design Construction Integration and test Release

Iteration Workflows
A workflow is a set of activities, performed by workers in some 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 some extent. Result of an iteration is called a baseline.
The difference between it and the previous baseline is an increment.

The Structure of UP
UP divides the software development life cycle into four phases 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 phase and for different software development projects


Example Project Lifecycle using UP


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

Workers, Activities, Artifacts

A Worker is a person who for a period of time will have specific 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 a worker An Artifact is a tangible piece of information that is created, changed and used by workers when performing activities An artifact can be a model, a model element or a document.


UP: Overview of Activities for Workers in each workflow


Source: [Jacobson 1] Figure 12.3

Inception Phase
Focus is on requirements and analysis workflows Goals are:
Establish feasibility Create a business case to demonstrate project will deliver business benefits Capture essential requirements To help scope the system Identify critical risks

Lifecycle objectives See textbook Table 2.1


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

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


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

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


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)

Correct defects Prepare user sites for the software; tailor software to operate at the user site Conduct a post-project review

Milestone: Product Release


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 understanding of the system requirements To define the boundaries of the system To provide a basis for planning the technical content of iterations To provide a basis for estimating cost/time to develop

Activities of the Requirements Workflow (1)

Source: Arlow


Activities of the Requirements Workflow (2)


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

The aim of Analysis is to produce an analysis model
Focuses on what the system needs to do

2 main Artifacts produced by Analysis:

Analysis classes - model key concepts in the business domain. Use case realizations

Key Activities performed for Analysis Workflow:

Architectural Analysis Analyse a use case Analyse a class Analyse a package


Analysis Workflow - Activities

Source: Jacobson

Comparing Use Case and Analysis Models

Use Case Model Analysis Model

Described using the language of the customer/client organisation External view of the system Structured by use cases; gives structure to the external view Used primarily as a contract between the customer and the developers on what the system should and should not do
Source: Jacobson: Table 8.1

Described using the language of the developers Internal view of the system Structured by stereotypical classes and packages; gives structure to the internal view Used primarily by developers to understand how the system should be shaped, i.e. designed and implemented

Comparing Use Case and Analysis Models (2)

Use Case Model Analysis Model

May contain redundancies, inconsistencies, etc. among requirements Captures the functionality of the system, including architecturally significant functionality

Should not contain redundancies, inconsistencies, etc. among requirements Outlines how to realize the functionality within the system, including architecturally significant functionality; works as a first cut at design Defines use-case realizations, each one representing the analysis of a use case from the use-case model

Defines use cases that are further analysed in the analysis model

Source: Jacobson: Table 8.1


Design Workflow - Overview

The focus of work late in elaboration phase, and early in construction phase Aims to produce the design model
Whereas Analysis focuses on what the system needs to do, the Design Model focuses on how this functionality will be implemented

Key activities:
Architectural Design Design a use case Design a class Design a subsystem


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 into the design model


Design Workflow - Activities

Source: Jacobson

Comparing Analysis and Design models

Analysis Model
Conceptual model, because it is an abstraction of the system and avoids implementation issues Design-generic (applicable to several potential designs)

Design Model
Physical model, because it is a blueprint of the implementation

Not generic, but specific for an implementation

Three (conceptual) stereotypes Any number of (physical) on classes: control, entity, stereotypes on classes, and boundary depending on implementation language

Source: Jacobson: Table 9.1

Comparing Analysis and Design models (2)

Analysis Model
Outlines the design of the system, including its architecture Defines a structure that is an essential input to shaping the system including creating the design model

Design Model
Manifests the design of the system, including its architecture

Shapes the system while trying to preserve the structure defined by the analysis model as much as possible.


Source: Jacobson: Table 9.1

Implementation Workflow - Overview

The implementation workflow is the main focus of the construction 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 executable components onto particular hardware devices.


Implementation Workflow - Activities


Source: Jacobson

Test Workflow - Overview

Testing involves verifying that the implementation matches 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 the requirements are implemented appropriately.


Test Workflow - Activities


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

Before the next lecture session, read through Module 2 of the study guide, and the specified readings from Arlow and from Armour (on the Librarys web site)