Software Development Lecture 6 The Software Wolf Software

Software Development Lecture 6

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 either essence, technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity” F. P Brooks Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 2

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 3

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 4

Software Development and Life-cycle 1. 2. 3. 4. 5. 6. 7. • • Requirements phase Specification phase Design phase Implementation phase 5. Integration Phase Maintenance phase Retirement Many forms and variations of development process Presence of feedback loops between the various stages of software process Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 5

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 6

The domain of architecting The “why” The “what” Architecture Qualities Satisfies Architecture Constrain Architecture Representation Produces The “who” System Features S/W Requirements System Quality Attributes Technology Defines The “how” Follows Architect Process Skills Stakeholders Defines role Organization

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 8

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 9

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 10

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! Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 11

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 12

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 13

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 14

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 15

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 16

The principles of agile methods Principle 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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 17

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 18

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 19

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 the system reacts to internal and external events. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 20

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 22

Design Vs Architecture Vs Implementation • 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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 23

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 24

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

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

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

Architecture metamodel

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

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 subsystems; – 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 Control system, • Management information system, • CAD system and CASE tools

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 – • Client must know the existence of server and the services offered – • A network that allow clients to access the services 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

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 38

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 Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 39

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.

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. Adv Software Engineering, By Asst Prof Athar Mohsin, MSCS 19, MCS-NUST 41

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 Local information repositories Internet M IC on DE ito rin g ICDE Repository ICDE Recording Software Analyst 3 rd Party Tools

ICDE Use Cases • 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 • 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. Adv Software Engg, MSCS 18, Asst Prof Athar Mohsin, MCS-NUST 45

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.

ICDE version 2. 0 • ICDE Major changes for next version focused on – Support 3 rd 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 3 rd party tool support or release to full production environment Business Goal Encourage third party tool developers Supporting Technical Objective 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 Adv Software Engg, MSCS 18, Asst Prof Athar Mohsin, MCS-NUST 47

Architecturally Significant Requirements for ICDE v 2. 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 3 rd 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 event 3. Return to user thread 5. Write event to ICDE database queue 2. Write event to queue 4. Read event from 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 – 24 x 7 x 52 (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 Interoperability through an API facade Application API Third Party Application Data Interoperability achieved by direct data access • 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 …

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