COMMONWEALTH OF AUSTRALIA

FIT2005 System Analysis, Design & Architecture

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

Module 1: Introducing UML and UP

www.monash.edu.au
2

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.
3 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 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)

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

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.

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.

Some software systems intended for Private Persons

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

When is a software system acquired?

Three key reasons (Oz 2004):
An opportunity A current problem A directive

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

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.

10

Who creates new software systems?

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

Roles
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

11

12

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

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

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)
13 14

UML A Visual Language

UML is a general purpose visual language
FIT2005 System Analysis, Design & Architecture

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)

UML An Introduction
www.monash.edu.au
16

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

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!

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

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

17

18

UML Structure (2)

Types of things: Structural things nouns
The subjects of the model, such as classes, use cases, collaborations

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)

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.

19

20

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

UML Structure
UML consists of:
Building blocks Common Mechanisms Architecture

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

21

22

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

UML Structure (6)

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

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

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

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

Tagged values
Properties associated with model elements: name-value pair E.g. {language = Java} {author = Ken Smith}
24

23

UML Structure
UML consists of:
Building blocks Common Mechanisms Architecture

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

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

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
26

25

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

FIT2005 System Analysis, Design & Architecture

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

The Unified Process An Overview

www.monash.edu.au
28

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

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

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
29 30

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
31 32

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

Example Project Lifecycle using UP

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

33

34

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

UP: Overview of Activities for Workers in each workflow

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.

35

36

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
[Quantifiable]

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:
Lifecycle objectives See textbook Table 2.1

Milestone: Life Cycle Architecture

37 38

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

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
To complete all requirements, analysis and design To evolve the architectural baseline (from Elaboration) into the final system

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

Milestone: Software system finished, ready for beta testing

39 40

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

Activities of the Requirements Workflow (1)

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
41 42

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

43

44

Analysis Workflow - overview

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

Analysis Workflow - Activities

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

Source: Jacobson
45 46

Comparing Use Case and Analysis Models

Use Case Model Analysis Model

Comparing Use Case and Analysis Models (2)

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
47

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
Continued
48

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

Artifacts of Design Models

A Design Model consists of: Subsystems Design classes Interfaces Use Case Realisations Design Deployment Diagrams Architectural Description

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

Often the analysis model evolves into the design model

49 50

Design Workflow - Activities

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
51 52

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

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.

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.

53

Source: Jacobson: Table 9.1

54

Implementation Workflow - Activities

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.

55

Source: Jacobson

56

Test Workflow - Activities

Homework
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)
57 58