Unit III

System Models

2

Objectives

• To explain why the context of a system should be modelled as part of the RE process

• To describe behavioural modelling, data modelling and object modelling

• To introduce some of the notations used in the Unified Modeling Language (UML)

• To show how CASE workbenches support system modelling

3

Topics covered

• Context models

• Behavioural models

• Data models

• Object models

• CASE workbenches

4

System Model

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers.

Different models present the system from different perspectives• External perspective showing the system’s

context or environment;• Behavioural perspective showing the behaviour

of the system;• Structural perspective showing the system or data

architecture.

5

System models weaknesses

• They do not model non-functional system requirements

• They do not usually include information about whether a method is appropriate for a given problem

• They may produce too much documentation

• The system models are sometimes too detailed and difficult for users to understand

6

Examples- System Model types created during Analysis

Architectural model : shows main & sub-systems that make up a system.

Composition model : shows how entities are composed of other entities.

Classification model : shows how entities have common characteristics.

Data flow model : shows how the data is processed at different stages.

Stimulus/response model : shows the system’s reaction to events.

7

1. Context models

• Context models are used to illustrate the boundaries of a system

• Social and organisational concerns may affect the decision on where to position system boundaries

• Architectural models show the a system and its relationship with other systems

8

The context of an ATM system

Auto-tellersystem

Securitysystem

Maintenancesystem

Accountdatabase

Usagedatabase

Branchaccounting

system

Branchcountersystem

9

Process models

Simple block/architectural diagrams do not show the relationships between the system block and the surrounding context.

So Process Models are used to show

1. the data or control flow among the blocks (in system and out context)

2. the overall process and the processes that are supported by the system.

Data flow models may be used to show the processes and the flow of information from one process to another.

10

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails plusblank order

form

Spec. +supplier +estimate

Supplier listEquipment

spec.

Equipment procurement process

Boundary of the system to be developed

11

2. Behavioural models

• Behavioural models are used to describe the overall behaviour of a system.

• Two types of behavioural model are:

– Data flow models that show how data is processed as it moves through the system;

– State machine models that show the systems response to events.

• These models show different perspectives so both of them are required to describe the system’s behaviour.

12

2.1 Data-flow models

• Data flow diagrams (DFDs) may be used to model the system’s data processing.

• These show the processing steps as data flows through a system.

• DFDs are basic part of many analysis methods.

• DFDs model the system from a functional perspective.

• Tracking and documenting how the data associated with a

process is helpful to develop an overall understanding of the system.

13Order processing DFD

Completeorder form

Orderdetails +

blankorder form

Validateorder

Recordorder

Send tosupplier

Adjustavailablebudget

Budgetfile

Ordersfile

Completedorder form

Signedorder form

Signedorder form

Checked andsigned order

+ ordernotification

Orderamount

+ accountdetails

Signedorder form

Orderdetails

14

Insulin pump DFD

Insulinrequirementcomputation

Blood sugaranalysis

Blood sugarsensor

Insulindelivery

controller

Insulinpump

Blood

Bloodparameters

Blood sugarlevel

Insulin

Pump controlcommands Insulin

requirement

15

2.2 State machine models

These model the behaviour of the system in response to external and internal events.

State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another.

State charts are an integral part of the UML and are used to represent state machine models.

16

State charts

Allow the decomposition of a model into sub-models.

A brief description of the actions is included following the ‘do’ in each state.

Can be complemented by tables describing the states and the stimuli.

17

Microwave oven model

Full power

Enabled

do: operateoven

Fullpower

Halfpower

Halfpower

Fullpower

Number

Dooropen

Doorclosed

Doorclosed

Dooropen

Start

do: set power= 600

Half powerdo: set power

= 300

Set time

do: get numberexit: set time

Disabled

Operation

Cancel

Waiting

do: displaytime

Waiting

do: displaytime

do: display 'Ready'

do: display'Waiting'

Timer

Timer

18

Microwave oven state description

State Description

Waiting The oven is waiting for input. The display shows the current time.

Half power The oven power is set to 300 watts. The display shows ‘Half power’.

Full power The oven power is set to 600 watts. The display shows ‘Full power’.

Set time The cooking time is set to the user’s input value. The display shows the cooking time selected and is updated as the time is set.

Disabled Oven operation is disabled for safety. Interior oven light is on. Display shows ‘Not ready’.

Enabled Oven operation is enabled. Interior oven light is off. Display shows ‘Ready to cook’.

Operation Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display shows ‘Cooking complete’ while buzzer is sounding.

19

Microwave oven stimuli

20

3. Data models

Used to describe the logical structure of data processed by the system.

An Entity-Relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes

No specific notation provided in the UML but objects and associations can be used.

21

Library semantic model

Source

titlepublisherissuedatepages

1

Article

titleauthorspdf filefee

has-links

1

Buyer

nameaddresse-mailbilling info

places

fee-payable-to

n

1

n

published-in

deliversin

m n

1

1

1

CopyrightAgencynameaddress

Country

copyright formtax rate

1

Order

order numbertotal paymentdatetax status

in

1

22

Data Dictionaries

• Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included.

• Advantages

– Supports name management and avoid duplication;

– Storage of organisational knowledge, linking analysis, design and implementation.

23

Name Description Type Date

Article Details of the published article Entity 30.12.2002

Authors The names of the authors attribute 30.12.2002

Buyer The person or organization that orders a copy of the article

Entity 30.12.2002

Fee-payable -to

A 1:1 relationship b/n article & Copyright agency

Relation 29.12.2002

Address The address of the Buyer Attribute 31.12.2002

Example of Data Dictionary Entries

24

Structured Methods

• Provide a frame work for detailed system modeling

• Define a process that may be used to derive these models and set of rules and guidelines that apply to the models.

• Standard documentation is produced for the system

• Case tools are available for support the method.

• Case tools allow user to generate a program from the information provided in the system model.

25

Report generationfacilities

Forms Creation Tools

Code generator Query LanguageFacilities

Import / export facilities

Design, Analysis &Checking Tools

Central Information

repository

Data Dictionary

Structured diagramming tools

Components of a Case Tool for

structured method support

UNIT-III

DESIGN ENGINEERING

2727

Purpose of Design

• Design is where customer requirements, business needs, and technical considerations all come together in the formulation of a product or system

• The design model provides detail about the software data structures, architecture, interfaces, and components

• design model can be assessed for quality and be improved before code is generated and tests are conducted– Does the design contain errors, inconsistencies, or omissions?– Are there better design alternatives?– Can the design be implemented within the constraints, schedule, and

cost that have been established?

28

• Software design is an iterative process through which requirements are translated into a blueprint for constructing the software

– Design begins at a high level of abstraction that can be directly traced back to the data, functional, and behavioral requirements

– As design iteration occurs, subsequent refinement leads to design representations at much lower levels of abstraction

2929

From Analysis Model to Design Model• Each element of the analysis model provides information that is

necessary to create the four design models– The data/class design transforms analysis classes into design

classes along with the data structures required to implement the software

– The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system

– The interface design describes how the software communicates with systems that interoperate with it and with humans that use it

– The component-level design transforms structural elements of the software architecture into a procedural description of software components

(More on next slide)

3030

From Analysis Model to Design Model (continued)

Data/Class Design

(Class-based model, Behavioral model)

Architectural Design

(Class-based model, Flow-oriented model)

Interface Design

(Scenario-based model, Flow-oriented modelBehavioral model)

Component-level Design

(Class-based model, Flow-oriented modelBehavioral model)

31

The Design Model

Process dimension - indicates design model evolution as design tasks are executed during software process • Architecture elements • Interface elements • Component-level elements • Deployment-level elements

Abstraction dimension - represents level of detail as each analysis model element is transformed into a design equivalent and refined – High level (analysis model elements) – Low level (design model elements)

Many UML diagrams used in the design model are refinements of diagrams created in the analysis model.

32

The Design Model

p r o c e s s d i m e n s i o n

a rc h it e c t u re

e le m e n t s

in t e rfa c e

e le m e n t s

c o m p o n e n t -le v e l

e le m e n t s

d e p lo ym e n t -le v e l

e le m e n t s

lo w

h ig h

class diagrams analysis packages CRC models collaboration diagrams

use-cases - text use-case diagrams activity diagrams swim lane diagrams collaboration diagrams data flow diagrams

control-flow diagrams processing narratives

data flow diagrams control-flow diagrams processing narratives

state diagrams sequence diagrams

state diagrams sequence diagrams

design class realizations subsystems collaboration diagrams

design class realizations subsystems collaboration diagrams

refinements to:

deployment diagrams

class diagrams analysis packages CRC models collaboration diagrams

component diagrams design classes activity diagrams sequence diagrams

refinements to:component diagrams design classes activity diagrams sequence diagrams

design class realizations subsystems collaboration diagrams component diagrams design classes activity diagrams sequence diagrams

a n a ly s is m o d e l

d e s ig n m o d e l

Requirement s : cons t raint s int eroperabilit y t arget s and configurat ion

technical interface design Navigation design GUI design

33

1. Data Design

High level model depicting user's view of the data or information

Translation of data model into database is critical to achieving system business objectives

Reorganizing databases into data warehouse enables data mining or knowledge discovery that can impact success of business itself

34

2. Architectural Design

Derived from • Information about the application domain

relevant to software • Relationships and collaborations among

specific analysis model elements • Availability of architectural patterns and styles

Usually depicted as a set of interconnected systems that are often derived from the analysis packages

35

3. Interface Design

Interface is a set of operations that describes the externally observable behavior of a class and provides access to its operations

Important elements • User interface (UI)

• External interfaces to other systems

• Internal interfaces between various design components

Modeled using UML collaboration diagrams

36

UML Interface representation for control panel

C o n t r o l P a n e l

L C D d i s p l a y L E D i n d i c a t o r s k e y P a d C h a r a c t e r i s t i c s s p e a k e r w i r e l e s s In t e r f a c e

r e a d K e y S t r o k e ( ) d e c o d e K e y ( ) d i s p l a y S t a t u s ( ) l i g h t L E D s ( ) s e n d C o n t r o l M s g( )

F ig u r e 9 . 6 U M L in t e r f a c e r e p r e s e n t a t io n f o r C o n t r o l P a n e l

K e y P a d

r e a d K e y s t r o k e( ) d e c o d e K e y ( )

< < in t e r f a c e > >

W ir e le s s P D A

K e y P a d

M o b i le P h o n e

37

4. Component-Level Design

Describes the internal detail of each software component

Defines • Data structures for all local data objects

• Algorithmic detail for all component processing functions

• Interface that allows access to all component operations

Modeled using UML component diagrams, UML activity diagrams, and pseudocode (PDL)

38

UML component diagram for sensor management

SensorManagementSensor

39

5. Deployment-Level Design

Indicates how software functionality and subsystems will be allocated within the physical computing environment

Modeled using UML deployment diagrams

40

UML Deployment diagram for safeHome

Figure 9.8 UML deployment diagram for SafeHome

Personal computer

Security

homeManagement

Surveillance

communication

Control Panel CPI server

Security homeownerAccess

externalAccess

41

Chapter-10

Creating An Architectural Design

42

10.1 Software Architecture

What is Architecture ?• The architecture is not the operational software.

Rather, it is a representation that enables a software engineer to:

(1) analyze the effectiveness of the design in meeting its stated requirements,

(2) consider architectural alternatives at a stage when making design changes is still relatively easy, and

(3) reduce the risks associated with the construction of the software.

43

Why is Architecture Important?

• Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.

• The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.

• Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together”.

44

10.2 Data Design

• At the architectural level …– Design of one or more databases to support

the application architecture– Design of methods for ‘mining’ the content of

multiple databases• navigate through existing databases in an attempt

to extract appropriate business-level information• Design of a data warehouse —a large,

independent database that has access to the data that are stored in databases that serve the set of applications required by a business

45

• At the component level …– refine data objects and develop a set of data

abstractions– implement data object attributes as one or

more data structures– review data structures to ensure that

appropriate relationships have been established

– simplify data structures as required

46

At the component level …

Set of Principles for Data specification:-

1. The systematic analysis principles applied to function and behavior should also be applied to data.

2. All data structures and the operations to be performed on each should be identified.

3. A data dictionary should be established and used to define both data and program design.

4. Low level data design decisions should be deferred until late in the design process.

47

5. The representation of data structure should be known only to those modules that must make direct use of the data contained within the structure.

6. A library of useful data structures and the operations that may be applied to them should be developed.

7. A software design and programming language should support the specification and realization of abstract data types.

48

Architectural Styles

Each style describes a system category that encompasses:

(1) a set of components (e.g., a database, computational modules) that perform a function required by a system,

(2) a set of connectors that enable “communication, coordination and cooperation” among components,

(3) constraints that define how components can be integrated to form the system, and

(4) semantic models that enable a designer to understand the overall properties of a system by analyzing the known properties of its constituent parts.

49

Architectural Styles• Data-centered architectures• Data flow architectures• Call and return architectures• Object-oriented architectures• Layered architectures

50

Data-Centered Architecture

51

Data-Centered Architecture

• A data store (eg., a file or databases) resides at the center of this architecture and is accessed frequently by other components.

52

Data Flow Architecture

53

Data Flow Architecture

• This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data.

54

Call and Return Architecture

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

55

Call and Return Architecture

• This architectural style enables a software designer to achieve a program structure that is relatively easy to modify and scale.

• Two substyles exist within this category:

1. Main program/subprogram architecture.

2. Remote procedure call architecture.

56

Layered Architecture

57

Layered Architecture

• A number of different layers are defined, each accomplishing a different kind of operation.

• At the outer layer, components service user interface operations.

• At the inner layer, components perform operating system interfacing.

58

Object Oriented Architecture

• The components of the system encapsulate data and the operations that must be applied to manipulate the data.

59

Architectural Patterns

• Concurrency— applications must handle multiple tasks in a manner that simulates parallelism.– operating system process management

pattern: It provides built-in OS features that allow components to execute concurrently.

– task scheduler pattern: The scheduler pattern contains a set of active objects that each contains a tick() operation. The scheduler periodically invokes tick() for each object.

60

• Persistence— Data persists if it survives past the execution of the process that created it. Two patterns are common: – a database management system pattern that

applies the storage and retrieval capability of a DBMS to the application architecture.

– an application level persistence pattern that builds persistence features into the application architecture.

• Distribution— the manner in which systems or components within systems communicate with one another in a distributed environment.– A broker acts as a ‘middle-man’ between the

client component and a server component.

61

Architectural Design

The design process for identifying the sub-

systems making up a system and the

framework for sub-system control and

communication is architectural design

The output of this design process is a

description of the software architecture.

62

Architectural Design

• The software must be placed into context– the design should define the external entities (other

systems, devices, people) that the software interacts with and the nature of the interaction

• A set of architectural archetypes should be identified– An archetype is an abstraction (similar to a class) that

represents one element of system behavior

• The designer specifies the structure of the system by defining and refining software components that implement each archetype

63

Architectural Context

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses

64

Architectural Context

• Use the architectural context diagram to model the manner in which the system interacts with external entities

• Systems that interoperate with the target system are represented as – Superordinate systems - using the target system as part of

some higher level processing scheme – Subordinate systems - used by the target system to

provide data or processing needed to complete the target system

– Peer level systems - producing or consuming information needed by peers of the target system

– Actors - people or devices that interact with the system to produce or consume information needed for requisite processing

• Interfaces must be defined • All the data that flow into or out of the target system must be

identified

65

Archetypes

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator

66

Archetypes

• Node: Represents a cohesive collection of input and output elements of the home security function.

• Detector: An abstraction that encompasses all sensing equipment that feeds information into the target system.

• Indicator: An abstraction that represents all mechanisms for indicating that an alarm condition is occurring.

• Controller: An abstraction that depicts the mechanism that allows the arming or disarming of a node.( ability to communicate with one another.

67

Component Structure

SafeHome Executive

External Communication Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

68

Component Structure

• External communication management – Coordinates communication of the security function with external entities, for example , Internet-based systems external alarm notification.

• Control Panel Processing – manages all control panel functionality.

• Detector management – coordinates access to all detectors attached to the system.

• Alarm Processing – Verifies and acts on all alarm conditions.

69

Refined Component Structure

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive

70

Architectural Pattern & Architectural Style• An Architectural Pattern is a way of solving a recurring

architectural problem. MVC, for instance, solves the problem of separating the UI from the model. Senser-Controller-Actuator, is a pattern that will help you with the problem of actuating in face of several input senses.

• An Architectural Style, on the other hand, is just a name given to a recurrent Architectural Design. Contrary to a Pattern, it doesn't exist to "solve" a problem.

• Pipe & filter doesn't solve any specific problem, it's just a way of organizing your code. Client/server, Main program & subroutine and Abstract Data Types / OO, the same.

7171

3.2 Design Engineering

71

7272

Contents

1. Design process and Design quality,

2. Design concepts,

3. Design model.

72

Design Engineering

7373

1. Quality is established during Design2. Design is an iterative process through which requirements are

translated into a blueprint for constructing software3. Design sets the stage for construction

73

DESIGN PROCESS AND DESIGN QUALITY

Customer Requirements.

Business

NeedsTechnical considerations

Design means System /

Product (of high quality)

formulate

software data structures, architecture,

interfaces, components

Design creates a representation or model of the software. The design model provides detail about the

747474

Blue print for real estate

Car blue print

7575

Carried out with a series of 1. formal technical reviews (FTRs) or 2. design walkthroughs

3 Characteristics of a good design. Design must be 1. readable, understandable guide for those who

generate code, test and subsequently support the software.

2. Provide a complete picture of software, addressing the data, functional and behavioral domains

3. Implement all explicit requirements mentioned in the analysis model and must accommodate all of requirements desired by the customer.

75

Quality Assessment of Design

76

What is Formal Technical Review?

A method involving a structured encounter in which a group of technical personnel analyzes or improves the quality of the original work product as well as the quality of the method.

WALK-THROUGH 

A form of software peer review in which a designer/ programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. Informal way initiated by the author of the code.

7777

1. Uses recognizable architectural styles or patterns

2. Modular; that is logically partitioned into elements or subsystems

3. Distinct representation of data, architecture, interfaces and components

4. Appropriate data structures for the classes to be implemented

5. Independent functional characteristics for components

6. Interfaces that reduces complexity of connection

7. Repeatable method77

7878

FURPS

Hey, What is

FURPS?

7979

808080

Functionality Feature set and capabilities of programs Security of the overall system

Usability user-friendliness ConsistencyDocumentation

Reliability Evaluated by measuring the frequency and severity of failureMTTF (Mean time to failure). Ability to recover from failures

Performance is measured by processing speed, response time, resource consumption and efficiency

Supportability and Maintainability

ExtensibilityAdaptabilityServiceability

FURPS Quality Attributes

8181

1. Abstractions2. Architecture3. Patterns4. Modularity5. Information Hiding6. Functional Independence7. Refinement8. Re-factoring9. Design Classes

81

8282

82

Design Concepts

1. Abstraction1. Procedural abstraction – a sequence of instructions that have a specific and

limited function2. Data abstraction – a named collection of data that describes a data object

2. Architecture1. The overall structure of the software and the ways in which the structure

provides conceptual integrity for a system2. Consists of components, connectors, and the relationship between them

3. Patterns1. A design structure that solves a particular design problem within a specific

context2. It provides a description that enables a designer to determine whether the

pattern is applicable, whether the pattern can be reused, and whether the pattern can serve as a guide for developing similar patterns

(more on next slide)

8383

83

Design Concepts (continued)Modularity

1. Separately named and addressable components (i.e., modules) that are integrated to satisfy requirements (divide and conquer principle)

2. Makes software intellectually manageable so as to grasp the control paths, span of reference, number of variables, and overall complexity

Information hiding1. The designing of modules so that the algorithms and local data contained within

them are inaccessible to other modules2. This enforces access constraints to both procedural (i.e., implementation) detail

and local data structuresFunctional independence

1. Modules that have a "single-minded" function and an aversion to excessive interaction with other modules

2. High cohesion – a module performs only a single task 3. Low coupling – a module has the lowest amount of connection needed with other

modules

(more on next slide)

8484

84

Design Concepts (continued)

Stepwise refinement1. Development of a program by successively refining levels of procedure

detail2. Complements abstraction, which enables a designer to specify procedure

and data and yet suppress low-level details Refactoring

1. A reorganization technique that simplifies the design (or internal code structure) of a component without changing its function or external behavior

2. Removes redundancy, unused design elements, inefficient or unnecessary algorithms, poorly constructed or inappropriate data structures, or any other design failures

Design classes1. Refines the analysis classes by providing design detail that will enable the

classes to be implemented2. Creates a new set of design classes that implement a software

infrastructure to support the business solution

8585

85

Types of Design Classes

1. User interface classes – define all abstractions necessary for human-computer interaction (usually via metaphors of real-world objects)

2. Business domain classes – refined from analysis classes; identify attributes and services (methods) that are required to implement some element of the business domain

3. Process classes – implement business abstractions required to fully manage the business domain classes

4. Persistent classes – represent data stores (e.g., a database) that will persist beyond the execution of the software

5. System classes – implement software management and control functions that enable the system to operate and communicate within its computing environment and the outside world

8686

86

Characteristics of a Well-Formed Design Class

1. Complete and sufficient1. Contains the complete encapsulation of all attributes and methods that exist for

the class2. Contains only those methods that are sufficient to achieve the intent of the

class 2. Primitiveness

1. Each method of a class focuses on accomplishing one service for the class3. High cohesion

1. The class has a small, focused set of responsibilities and single-mindedly applies attributes and methods to implement those responsibilities

4. Low coupling1. Collaboration of the class with other classes is kept to an acceptable minimum2. Each class should have limited knowledge of other classes in other subsystems

8787

The Design Model

Data/Class Design

Architectural Design

Interface Design

Component-level Design

8888

Process Dimension (Progression)

Abs

trac

tion

Dim

ensi

on

Data/ClassElements

InterfaceElements

ArchitecturalElements

Component-levelElements

Deployment-levelElements

Dimensions of the Design Model

Analysis model

Design model

Low

High

8989

Analysis viewed in two different dimensions as process dimension and abstract dimension.

Process dimension indicates the evolution of the design model as design tasks are executed as part of software process.

Abstraction dimension represents the level of details as each element of the analysis model is transformed into design equivalent

Data Design elements1. -- Data design creates a model of data that is represented at a

high level of abstraction2. -- Refined progressively to more implementation-specific

representation for processing by the computer base system3. -- Translation of data model into a data base is pivotal to

achieving business objective of a system4. The design of data structures and the associated algorithms

required to manipulate them is essential to the creation of high quality applications.

89

9090

Architectural design elementsArchitectural design for software is the equivalent to the floor plan of

a house.ex: architectural design for s/w is the equivalent to the floor plan of a

house. Floor plan depicts the overall layout of the rooms, their size, shape and relationship to one another. and the door and windows that allow movement into and out of the rooms

Architectural design elements give us an overall view of s/w.

Derived from three sources(1) Information about the application domain of the software(2) Analysis model such as dataflow diagrams or analysis classes.(3) availability of Architectural pattern and styles

90

9191

Interface Design elements-- Set of detailed drawings constituting:(1) User interface(2) External interfaces to other systems devices etc(3) Internal interfaces between various components

The interface design elements for software tell how information flows into and out of the system and how it is communicated among the components defined as part of the architecture.

ex: size and shape of the doors and windows , the way in which utilities connections( electricity, water, gas ,telephone) come into to the house and are distributed among the rooms

91

9292

Deployment(distribution of forces)level design elements

1. -- Indicates how software functionality and subsystem will be allocated with in the physical computing environment

2. -- UML deployment diagram is developed and refined ex: safe home productsComponent level design elements1. --Fully describe the internal details of each software component2. UML diagram can be used

ex: the component level design for the software is equivalent to a set of detailed drawings for each room in a house. These includes wiring and plumbing within each room, the location of electrical switches, sinks, showers, tubs, cabinets etc etc…

92

9393

Definition:-

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components and the relationship among them.

93

94

• The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design.

• The output of this is a description of the software architecture.

design process

o/p

Visionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller

Packing robot control system

95

Design is about how the internal components of the system interact with each other.

Software Architecture focuses more on the interaction between the externally visible components of the system .

Design is about how we want to achieve that.

Software Architecture is more about what we want the system to do.

S/w design is at lower level of abstraction and is more detailed than architecture.

Software architecture is at a higher level of abstraction than the Software Design.

Design deals with more of data structure s/ classes and functionality.

Software Architecture is concerned with issues beyond the data structures and algorithms used in the system.

95

9696

1. Software Architecture is not the operational software.

2. It is a representation that enables a software engineer to Analyze the effectiveness of the design in

meeting , its stated requirements. consider architectural alternative at a stage when

making design changes is still relatively easy . Reduces the risk associated with the construction

of the software.

96

9797

We wouldn’t attempt to build a house without a blueprint. it provides a big picture and ensures that you’ve got it right.

Three key reasons--Representations of software architecture enables for

communication and understanding between stakeholders

--Highlights early design decisions to create an operational entity.

--constitutes a model of software components and their interconnection and how its components work together.

97

Why Is Architecture Important?

9898

1. The data design action translates data objects defined as part of the analysis model into data structures at the component level and a database architecture at application level when necessary.

98

Analysis

Data Objects

Data Structures

Application

Database

Component/ Programming level

9999

1. Today, businesses uses large amounts of data, that data is stored in db. this data bases serving many applications encompassing hundreds of gigabytes of data.

2. The challenge is to extract useful information. To solve this challenge, business IT community has developed a data mining technique. Also called know discovery in databases(KDD).

3. However, the existence of multiple databases, their different structures, the degree of detail contained with the databases, and many other factors make data mining difficult within an existing data base environment.

4. Alternative solution is called as data warehouse, adds additional layer to the data architecture.

99

100100

1. Data structure at programming level

2. Database at application level

3. Data warehouse at business level.

100

101101

Principles for data specification:1. Proper selection of data objects and data and data models

2.Identification of attribute and functions and their encapsulation of these within a class

3.Mechanism for representation of the content of each data object. Class diagrams may be used

4.Refinement of data design elements from requirement analysis to component level design.

5.Information hiding

6.A library of useful data structures and operations be developed.

7.Software design should support the specification and realization of abstract data types. 101

102102

Describes a system category that encompasses:

(1) a set of components

(2) a set of connectors that enables “communication and coordination

(3) Constraints(limitations or restrictions) that define how components can be integrated to form the system

(4) Semantic models to understand the overall properties of a system.– Constraints may be:

• Topological• Behavioral• Communication-oriented• etc. etc.

The intent is to establish a structure for all components of the system

102

103

• The main difference is that a pattern can be seen as a solution to a problem, while a style is more general and does not require a problem to solve for its appearance

• Differences

Architectural Styles Design Patterns

Few Many

Large-scale system organization

Localized, small-scale design solutions

104104104

105105105

A data store( file or database) resides at the center of this architecture and is accessed frequently by other components that updates, add, delete or otherwise modify data within the store.

the above fig illustrate a data –centered style. Client s/w access a central repository.

In some cases the data repository is passive. That is, client software accesses the data independent of any changes to the data. A variation on this approach transforms the repository into a blackboard that sends notification to client software when data of interest to the client changes.

Data –centered architecture promotes integrability. That is, existing components can be changed and new client components added to the architecture without concern about other clients( because client components operate independently)

In addition, data can be passed among clients using the blackboard mechanism.

106106

1. Shows the flow of input data, its computational components and output data

2. Structure is also called pipe and Filter

3. Pipe provides path for flow of data

4. Filters manipulate data and work independent of its neighboring filter

5. If data flow degenerates into a single line of transform, it is termed as batch sequential.

106

107107107

108108

Achieves a structure that is easy to modify and scaleTwo sub styles(1) Main program/sub program architecture-- Classic program structure-- Main program invokes a number of components, which in turn

invoke still other components(2) Remote procedure call architecture -- Components of main program/subprogram are distributed

across computers over network

108

109109109

110110110

111111

1. The components of a system encapsulate (enclose(something) in) data and the operations

2. Communication and coordination between components is done via message passing

111

112112112

113113

1. A number of different layers are defined

2. Inner Layer( interface with OS)

3. Intermediate Layer provides Utility services and application s/w function

4. Outer Layer (User interface)

Each layer accomplishing operations that progressively become closer to the machine instruction set.

113

114114114

115115115

116116

A template that specifies approach for some behavioral characteristics of the system

Patterns are imposed(force on someone) on the architectural stylesPattern Domains

1.Concurrency(done at same time)--Handles multiple tasks that simulates parallelism.--Approaches(Patterns)(a) Operating system process management pattern(b) A task scheduler pattern2.Persistence--Data survives past the execution of the process--Approaches (Patterns)(a) Data base management system pattern(b) Application Level persistence Pattern( word processing software)

116

117117

3.DistributionSystems or components within systems communicate with one another in a

distributed environment.-- Addresses the communication of system in a distributed environment--Approaches(Patterns)(a) Broker Pattern-- Acts as middleman between client and server.

117