Upload
mabel-newton
View
214
Download
0
Tags:
Embed Size (px)
Citation preview
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