Software Development

Software Development

Lecture 6

Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 2

The Software Wolf• Software is like a wolf

– it looks normal until the moon comes out and it turns into a monster if:

• Missed deadlines• Over budgets• Not to desired quality

• We want the silver bullet to kill the monster– something to make software costs drop as rapidly as

computer hardware costs do.“As we look to the horizon of a decade hence, we see no silver bullet.

There is no single development, in eitheressence, technology or in management technique,

that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity” F.P Brooks


Essential vs. Accidental Difficulties• Essential: a characteristic of software

– Difficulties inherent in the nature of software– Data sets, relationships among them, algorithms, and function

invocation– Inherent properties of the essence of modern software

system: Complexity, Conformity, Changeability, Invisibility

• Accidental: a problem in today’s production methods – Difficulties related to the actual production process.

• Complexity, varied domain, changeability and invisibility• The essence is what the software does and the accidents are

the technology by which the software does the essence or by which the software is developed. Brooks – The requirements are the essence, while the language, tools,

and methods used are the accidents.


Software Communities• The software development community has split

– Web designers– Analysts/designers– Traditional skilled programmers– Software hackers– Academic community– Licensed company X internals specialists– …

• These groups don’t understand each other’s languages, tools, and work methods– Each group has sub-groups who don’t understand each other’s

languages, tools, and work methods• E.g. C, C++, Java


Software Development and Life-cycle1. Requirements phase2. Specification phase3. Design phase4. Implementation phase5.6. Maintenance phase7. Retirement

5. Integration Phase

• Many forms and variations of development process

• Presence of feedback loops between the various stages of software process


Software Development• Requirements (Specification) phase

– ... answers the question: what?– ... starts with the definition of requirements by

the requirements specification team• Software Development phase

– .. answers the question: how?– SW that is expected to meet the specification

must be produced.• Design phase: alternative solutions to how the

intended goals are accomplished• Implementation phase: actual code development

The domain of architecting

ArchitectureQualities

Process

Architecture Representation

The “what” The “why”

The “how”The “who”

SystemFeatures

Architecture S/W Requirements

SystemQuality Attributes

Satisfies

Constrain

Organization

Architect

Skills

Stakeholders Defines role

Produces

Follows

DefinesTechnology


Attributes of good software• SW should deliver the required functionality and

performance to the user and should be maintainable, dependable and acceptable.

• Maintainability– Software must evolve to meet changing needs;

• Dependability– Software must be trustworthy;

• Efficiency– Software should not make wasteful use of system resources;

• Acceptability– Software must accepted by the users for which it was designed. This

means it must be understandable, usable and compatible with other systems.


Timeline • Code & Fix

– Software development started off as a messy activity• Not much of a plan, • The short term design decisions

• Traditional methodologies: Heavyweight – Elicitation & documenting complete requirements– Architectural & High Level Design, Development and inspections

• For some practitioners process centric view of development is frustrating– Waterfall

• Lightweight methodologies- Agile practices – Several consultants have independently developed

methodologies and practices, based on iterative enhancements• Gaining popularity in industry


Heavyweight Methodologies• Considered to be the traditional way of developing software:

– Based on a sequential series of steps• Require defining and documenting a stable set of requirements• Many different heavyweight methodologies

– Waterfall, RUP, Spiral

• Heavyweight Characteristics– Predictive approach:

• Plan out a large part of the software process in great detail for a long span of time

– Comprehensive Documentation: • the big design upfront (BDUF) process

– Process Oriented:• Define a process that will work well for all

– Tool Oriented:• Project management tools, Code editors, compilers, etc


Heterogeneity in software Engineering • There will not be consensus on hardware

platforms• There will not be consensus on operating

systems• There will not be consensus on network

protocols• There will not be consensus on programming

languages• There must be consensus on models,

interfaces and interoperability!


Unified Process • All efforts, including modeling, is organized into workflows and is

performed in an iterative and incremental manner. Key features are:– It uses a component based architecture which creates a system that is

easily extensible, promotes software reuse and intuitively understandable. • The component commonly being used to coordinate object oriented programming

projects. – Uses visually modeling software such as UML:

• UML represent its code as a diagrammatic notation to allow less technically competent individuals who may have a better understanding of the problem to have a greater input.

– Manage requirements using use-cases and scenarios:• Use-cases and scenarios are very effective at both capturing functional

requirements and help in keeping sight of the anticipated behaviors of the system. – Design is iterative and incremental:

• This helps reduce project risk profile, allows greater customer feedback and help developers stay focused.

– Verifying software quality is very important in a software project. • UP assists in planning quality control and assessment built into the entire process

involving all member of the team.


Feature Driven Development• Does not cover the entire software development

process but focuses on the design and building phases:– The first three phases are done at the beginning of the

project. – The last two phases are the iterative part of the process:

• These supports the Agile Development with quick adaptations to late changes in requirements and business needs.


Feature Driven Development• Develop an Overall Model:

– A high level review of the system scope and its context is performed by the domain expert.

• Documented requirements such as use cases or functional specifications are developed.

• Build a Features List:– A categorized list of features to support the requirements is

produced • Plan by Feature:

– The development team orders the feature sets according to their priority and dependencies.

• Schedule and milestones are set for the feature sets.

• Design by Feature & Build by Feature:– Features are selected from the feature set.

• The design by feature and build by feature are iterative procedures during which the team produces the sequence diagrams for the assigned features.


Rapid software development• Rapid development and delivery is now often the

most important requirement for software systems– Businesses operate in a fast –changing requirement and it

is practically impossible to produce a set of stable software requirements

– Software has to evolve quickly to reflect changing business needs.

• Rapid software development– Specification, design and implementation are inter-leaved– System is developed as a series of versions with

stakeholders involved in version evaluation– User interfaces are often developed using an IDE and

graphical toolset.

Concurrentactivities

ValidationFinal

version

Development Intermediateversions

SpecificationInitial

version

Outlinedescription


Agile Methods • These methods:

– Focus on the code rather than the design– Are based on an iterative approach to software development– Are intended to deliver working software quickly and evolve this

quickly to meet changing requirements.• The aim of agile methods is to reduce overheads in the

software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.– Product development where a software company is developing a

small or medium-sized product for sale.• Custom system development within an organization, where there is a

clear commitment from the customer to become involved in the development process and where there are not a lot of external rules and regulations that affect the software.


The principles of agile methodsPrinciple Description

Customer involvement Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.

Incremental delivery The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.


Software Requirements Vs Design • In principle, requirements should state what the

system should do and the design should describe how it does this.

• In practice, requirements and design are inseparable– A system architecture may be designed to structure the

requirements;– The system may inter-operate with other systems that

generate design requirements;– The use of a specific architecture to satisfy non-functional

requirements may be a domain requirement.– This may be the consequence of a regulatory

requirement.


System Modeling • Process of developing abstract models of a system,

with each model presenting a different view or perspective of that system. – Representing a system using some kind of graphical

notation, which is now almost always based on notations in the Unified Modeling Language (UML).

• System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.– A flow chart visually models an algorithm's logic.– Pseudo code textually models an algorithm's logic.


UML• System modelling helps the analyst to understand the

functionality of the system and models are used to communicate with customers.– Activity diagrams:

• show the activities involved in a process or in data processing .– Use case diagrams:

• show the interactions between a system and its environment. – Sequence diagrams:

• show interactions between actors and the system and between system components.

– Class diagrams:• show the object classes in the system and the associations between

these classes.– State diagrams:

• show how the system reacts to internal and external events.

Software Design • “The process of defining the architecture,

components, interfaces, and other characteristics of a system or component” and “The result of [that] process.” IEEE 610.12.– As a process:

• software design is the software engineering life cycle activity in which software requirements are analyzed in order to produce a description of the software’s internal structure that will serve as the basis for its construction.

– As a result software design must describe the software architecture:

• How software is decomposed and organized into components and

• The interfaces between those components.


Design Process • Software design is generally considered a two-step process:

– Software architectural design (sometimes called top level design): • Describing software’s top-level structure and organization and identifying

the various components– Software detailed design:

• Describing each component sufficiently to allow for its construction.

• The output of this process is a set of models that record the major decisions that have been taken.

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specificationAlgorithm

specification

Requirementsspecification

Design activities

Design products


• Terms “architecture”, “design” and “implementation” can be viewed at varying degree of abstraction – complete details (“implementation”), – few details (“design”), and – the highest form of abstraction (“architecture”).

• Architecture:– An early stage of the system design process.

• Represents the link between specification and design processes.• Often carried out in parallel with some specification activities.

– It involves identifying major system components and their communications.

Design Vs Architecture Vs Implementation


Use of architectural models• As a way of facilitating discussion about the system

design – A high-level architectural view of a system is useful for

communication with system stakeholders and project planning because it is not cluttered with detail.

• Stakeholders can relate to it and understand an abstract view of the system. They can then discuss the system as a whole without being confused by detail.

• As a way of documenting an architecture that has been designed – The aim here is to produce a complete system model that

shows the different components in a system, their interfaces and their connections.

Architectural Design• Large Systems – Decomposed into smaller sub systems –

Provide some related set of services – Architectural design - Initial design process

• identify subsystems (major components) + establish control & communication framework

• “A description of the subsystems and components of a software system and the relationships between them.”– Architectural design – link between design & requirement

engineering processes– Advantage

• Stakeholder communication– Architecture may be used as a focus of discussion by system stakeholders.

• System Analysis– whether the system can meet its non-functional requirements.

• Large scale reuse– architecture may be reusable across a range of systems

26

Case Study-1 ATM• A bank has several automated teller machines (ATMs),

which are geographically distributed and connected via a wide area network to a central server.

• Each ATM machine has a card reader, a cash dispenser, a keyboard/display, and a receipt printer.

• By using the ATM machine, a customer can withdraw cash from either current or savings account, query the balance of an account, or transfer funds from one account to another.

• A transaction is initiated when a customer inserts an ATM card into the card reader. Encoded on the magnetic strip on the back of the ATM card are the card number, the start date, and the expiration date.

• The customer is allowed three attempts to enter the correct PIN; the card is confiscated if the third attempt fails.

• Cards that have been reported lost or stolen are also confiscated.

27

Case Study ATM• Before withdrawal transaction can be approved, the

system determines that sufficient funds exist in the requested account, that the maximum daily limit will not be exceeded, and that there are sufficient funds available at the local cash dispenser.

• If the transaction is approved, the requested amount of cash is dispensed, a receipt is printed containing information about the transaction, and the card is ejected.

• Before a transfer transaction can be approved, the system determines that the customer has at least two accounts and that there are sufficient funds in the account to be debited.

• For approved query and transfer requests, a receipt is printed and card ejected.

Auto-tellersystem

Securitysystem

Maintenancesystem

Accountdatabase

Usagedatabase

Branchaccounting

system

Branchcountersystem

Architecture metamodelSoftware

Architecture

Software Architecture Description

Architectural view

is made of

is represented byArchitecture

Design Process

produces

Form

Component

ConnectionArchitectural

Pattern

is a

is made of

Software Architects

are actors in

Logical view

Process view

Implemen- tation view

Deployment view

Requirements

satisfies

Architectural style

has

has

has

is a

System architecture

is part of

Architecture Style guide

Constraints

constrains

constrains

Use case view

relates to

Architectural Blueprint

depicts

Architecture and system characteristics• System Architecture affects the NFRs, A particular style

chosen for an application depends on NFRs– Performance

• Localise critical operations and minimise communications. • Use large rather than fine-grain components.

– Security• Use a layered architecture with critical assets in the inner layers.

– Safety• Localise safety-critical features in a small number of sub-systems.

– Availability• Include redundant components and mechanisms for fault tolerance.

– Maintainability• Use fine-grain, replaceable components.

Architectural conflicts• Potential Conflict of Architecture

– Performance (large grain components) & Maintainability (fine grain components)

• Using large-grain components improves performance but reduces maintainability.

– Availability & Security • Introducing redundant data improves availability but makes

security more difficult.– Safety & Performance

• Localising safety-related features usually means more communication so degraded performance.

• Some compromise must be found if both are important requirements

Architecture Design decisions • System architects make decisions on following:

– Generic application architecture, use as a template • Like MSOffice

– How to distribute the system across a number of processors• For larger systems, not needed for single processor

– The appropriate architecture for the target application• Like client – server

– How to decompose into module• Identify the subsystems

– How to control the operation of units in the system• How the execution of subsystem is controlled

– How will the architecture be evaluated • Compare with existing model

– How to document the architecture• May use graphical representations to describe the

working of system

Architectural Styles • Various authors have identified a number of

major architectural styles. – General structure

• (for example, layers, pipes and filters)– Distributed systems

• (for example, client-server, three tiers, broker)– Interactive systems

• (for example, Model-View-Controller, Presentation-Abstraction-Control)

– Others • (for example, batch, interpreters, process control, rule-

based).

Architectural models• Used to document an architectural design.• Static structural model:

– shows the major system components.• Dynamic process model:

– shows the process structure of the system.• Interface model that:

– sub-system interfaces.• Relationships model:

– data-flow model that shows sub-system relationships.• Distribution model:

– shows how sub-systems are distributed across computers.

The repository model• Sub-systems must exchange information and data

so that they can work together. • This may be done in two ways:

– All shared data is held in a central database or repository and may be accessed by all sub-systems;

– Each sub-system maintains its own database and passes data explicitly to other sub-systems.

• When large amounts of data are to be shared, – The repository model of sharing is most commonly used– Data is generated by one subsystem and used by other

• E.g., command and Control system, • Management information system, • CAD system and CASE tools

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

Client-server model• Client –Server model: A system model, where system is

organised as– A set of services, associated servers and clients that access the

services • Major components:

– A set of servers to offer services to other sub systems• Print server to offer printing services

– A set of clients to call the services offered by servers • These are the sub systems at their own

– A network that allow clients to access the services • Client must know the existence of server and the services

offered – Client send the request and has to wait for reply from server

• Both client and server may run on similar machine but normally client and server are distributed

CatalogueserverLibrary

catalogue

Videoserver

Film clipfiles

Pictureserver

Digitisedphotographs

Web server

Film andphoto info.

Client 1 Client 2 Client 3 Client 4

Internet

Abstract machine (layered) model• Used to model the interface of sub-systems.

– Organises the system into a set of layers (or abstract machines) each of which provide a set of services

– Each layer acts as an abstract machine• E.g., OSI model, computer as layered machine

• Supports the incremental development of sub-systems in different layers. – When a layer interface changes, only the adjacent layer is affected.

Control styles• The model for structuring a system are concerned

with how a system is decomposed into subsystem– To work as a system the subsystem must be

controlled • To provide right services at the right palace at right time

• Two generic control styles used in SW systems are:– Centralised control

• One sub-system has overall responsibility for control and starts and stops other sub-systems.

– Event-based control• Each sub-system can respond to externally generated

events from other sub-systems or the system’s environment.


Centralised control• A controller sub-system takes responsibility for managing

the execution of other sub-systems• Centralized control is divided into:

– Call-return model• control starts at the top of a function hierarchy and using function calls

moves downwards. – Applicable to sequential systems.

– Manager model• Applicable to concurrent systems. • One system component controls the stopping, starting and

coordination of other system processes

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram


Real-time system control• Suitable for soft real time

systems– Central manager controls the

set of processes associated with sensors and actuators

– System controller decides to start and stopping the process

• Depending on system state– Controller continuously loops

between sensors and processes

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses

Event-driven systems• Driven by externally generated events where the timing of

the event is the control of the sub-systems which process the event.

• Two principal event-driven models– Broadcast models. An event is broadcast to all sub-systems. Any

sub-system which can handle the event may do so;– Interrupt-driven models. Used in real-time systems where

interrupts are detected by an interrupt handler and passed to some other component for processing.

• Other event driven models include spreadsheets and production systems.

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4


Interrupt-driven systems• Used in real-time systems where fast response to an event is

essential.– There are known interrupt types with a handler defined for each

type.– Each type is associated with a memory location and a hardware

switch causes transfer to its handler.• Allows fast response but complex to program and difficult to

validate.

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

Case Study-2 ICDE • The Information Capture and Dissemination

Environment (ICDE) is part of a suite of software systems for providing intelligent assistance to professionals such as:– Financial analysts, scientific researchers and

intelligence analysts. • ICDE automatically captures and stores data

that records a range of actions performed by a user when operating a workstation.

Case study- ICDE System– Example, when a user performs a Google search, the

ICDE system will transparently store in a database:• The search query string• copies of the web pages returned by Google that the user

displays in their browser– This data can be used subsequently retrieved from the

ICDE database and used by third-party software tools that attempt to offer intelligent help to the user.

– These tools might interpret a sequence of user inputs, and try to find additional information to help the user with their current task.

– Other tools may crawl the links in the returned search results that the user does not click on, attempting to find potentially useful details that the user overlooks.

ICDE Schematic

ICDE M

onitorin

g

ICDERepository

ICDERecording Software

Local information repositories

Internet

Analyst

3rd Party Tools

Adv Software Engg, MSCS 18, Asst Prof Athar Mohsin, MCS-NUST 45

ICDE Use Cases

• The three major use cases:– Incorporate the capture of

user actions, – The querying of data from

the data store, and – The interaction of the third

party tools with the user.

ICDE

Analyst

3rd Party Tools

Data Store

Capture UserActions

Query User Actions

User Assistance

*

*

* *

*

*

*

*

*

*

*

*

• ICDE initial production:– Aim was to implement the Capture User Actions

use case.• Basically a complex, raw information capture tool, GUI

for looking at captured data

Case Study Context• ICDE production:

– Design was based on simple 2 tier client-server, single machine deployment

• Programmatic access to data through very complex SQL (38 tables, 46 views)

• The collection and analysis components were written in Java and access the data store directly using the JDBC API.

• The complete ICDE application executed on Microsoft Windows XP.

Adv Software Engg, MSCS 18, Asst Prof Athar Mohsin, MCS-NUST 47

ICDE version 2.0• ICDE Major changes for next version focused on

– Support 3rd party tool integration– Enhance data capture tools (GUI)on, testing, data access and large

production scale deployments (100’s of users)• Very few concrete requirements for the 3rd party tool support

or release to full production environmentBusiness Goal Supporting Technical Objective

Encourage third party tool developers

Simple and reliable programmatic access to data store for third party tools

Heterogeneous (i.e. non-Windows) platform support for running third party tools

Allow third party tools to communicate with ICDE users from a remote machine

Promote the ICDE concept to users

Scale the data collection and data store components to support up to 150 users at a single site

Low-cost deployment for each ICDE user workstation

Architecturally Significant Requirements for ICDE v2.0

• ICDE project requirements:• Heterogeneous platform support for access to ICDE

data• Instantaneous event notification (local/distributed)• Over the Internet, secure ICDE data access• Ease of programmatic data access

• ICDE Project team requirements:• Insulate 3rd party projects and ICDE tools from

database evolution• Reliability for multi-tool ICDE deployments• Scalable infrastructure to support large, shared

deployments• Minimize license costs for a deployment

• Unknowns• Minimize dependencies, making unanticipated

changes potentially easier

Quality Attributes of Architecture• Often know as –ilities

– Reliability– Availability– Portability– Scalability– Performance

• Part of a system’s NFRs– “how” the system achieves its functional requirements– The Application must be scalable

• “It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.”

Performance• Many examples of poor performance in enterprise

applications– Poor performance is killer

• Performance requires a:– Metric of amount of work performed in unit time– Deadline that must be met for correct operation.

• Throughput– A measure of the amount of work an application must perform in unit

time.• Work is typically measured in transactions per second (tps), or messages

processed per second (mps). – For example, an on-line banking application might have to guarantee it can

execute 1000 transactions per second from Internet banking customers. – An inventory management system for a large warehouse might need to

process 50 messages per second from trading partners.

• Response Time:– measure of the latency an application exhibits in processing a

request• Usually measured in (milli) seconds

ICDE Performance Issues• Enterprise applications often have strict performance

requirements, e.g.– 1000 transactions per second– 3 second average latency for a request

• Response time:– Overheads of trapping user events must be imperceptible to ICDE

users• Solution for ICDE client:

– Decouple user event capture from storage using a queue

1. Trap user event2. Write event to queue

3. Return to user thread 4. Read event from queue

5. Write event to ICDE database queue

Modifiability• Modifiability should be assessed in context of how a

system is likely to change– No need to facilitate changes that are highly unlikely to occur

- Over-engineering– Only relevant in the context of a given architectural solution.

• Components• Relationships• Responsibilities

• Modifiability of ICDE– The range of events trapped and stored by the ICDE client to

be expanded. • Third party tools to communicate new message types.

– Change database technology used– Change server technology used

Availability

• Key requirement for most IT applications• Measured by the proportion of the required time it is useable.

E.g.– 100% available during business hours– No more than 2 hours scheduled downtime per week– 24x7x52 (100% availability)

• Period of loss of availability determined by:– Time to detect failure– Time to correct failure– Time to restart application

• Strategies for high availability:– Eliminate single points of failure– Replication and failover– Automatic detection and restart

Integration

• Ease with which an application can be incorporated into a broader application context – Use component in ways that the designer did not

originally anticipate • widespread strategies for providing integration are:

– through data integration or providing an application programming interface (API).

• involves storing the data an application manipulates in ways that other applications can access

• Typically achieved by:– Programmatic APIs– Data integration

Integration Strategies

• Data – expose application data for access by other components

• API – offers services to read/write application data through an abstracted interface

• Each has strengths and weaknesses …

Application

Data

Third Party Application

API

Interoperability through an API facade

Interoperability achieved by direct data access

Acknowledgement

• Software Engineering by sommerville – Chapters 3,5,6 and 7

• SWEBOK– Chapter 3 Software Design

• Architecture, Design, Implementation– Amnon H. Eden & Rick Kazman

• Software Architecture in Practice, Len Bass, Paul Clements

Documents

Software Development