unit iii system models. 2 objectives to explain why the context of a system should be modelled as...
TRANSCRIPT
![Page 1: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/1.jpg)
Unit III
System Models
![Page 2: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/2.jpg)
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
![Page 3: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/3.jpg)
3
Topics covered
• Context models
• Behavioural models
• Data models
• Object models
• CASE workbenches
![Page 4: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/4.jpg)
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.
![Page 5: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/5.jpg)
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
![Page 6: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/6.jpg)
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.
![Page 7: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/7.jpg)
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
![Page 8: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/8.jpg)
8
The context of an ATM system
Auto-tellersystem
Securitysystem
Maintenancesystem
Accountdatabase
Usagedatabase
Branchaccounting
system
Branchcountersystem
![Page 9: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/9.jpg)
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.
![Page 10: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/10.jpg)
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
![Page 11: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/11.jpg)
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.
![Page 12: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/12.jpg)
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.
![Page 13: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/13.jpg)
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
![Page 14: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/14.jpg)
14
Insulin pump DFD
Insulinrequirementcomputation
Blood sugaranalysis
Blood sugarsensor
Insulindelivery
controller
Insulinpump
Blood
Bloodparameters
Blood sugarlevel
Insulin
Pump controlcommands Insulin
requirement
![Page 15: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/15.jpg)
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.
![Page 16: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/16.jpg)
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.
![Page 17: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/17.jpg)
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
![Page 18: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/18.jpg)
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.
![Page 19: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/19.jpg)
19
Microwave oven stimuli
![Page 20: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/20.jpg)
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.
![Page 21: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/21.jpg)
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
![Page 22: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/22.jpg)
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.
![Page 23: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/23.jpg)
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
![Page 24: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/24.jpg)
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.
![Page 25: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/25.jpg)
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
![Page 26: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/26.jpg)
UNIT-III
DESIGN ENGINEERING
![Page 27: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/27.jpg)
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?
![Page 28: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/28.jpg)
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
![Page 29: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/29.jpg)
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)
![Page 30: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/30.jpg)
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)
![Page 31: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/31.jpg)
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.
![Page 32: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/32.jpg)
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
![Page 33: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/33.jpg)
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
![Page 34: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/34.jpg)
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
![Page 35: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/35.jpg)
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
![Page 36: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/36.jpg)
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
![Page 37: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/37.jpg)
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)
![Page 38: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/38.jpg)
38
UML component diagram for sensor management
SensorManagementSensor
![Page 39: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/39.jpg)
39
5. Deployment-Level Design
Indicates how software functionality and subsystems will be allocated within the physical computing environment
Modeled using UML deployment diagrams
![Page 40: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/40.jpg)
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
![Page 41: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/41.jpg)
41
Chapter-10
Creating An Architectural Design
![Page 42: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/42.jpg)
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.
![Page 43: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/43.jpg)
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”.
![Page 44: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/44.jpg)
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
![Page 45: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/45.jpg)
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
![Page 46: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/46.jpg)
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.
![Page 47: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/47.jpg)
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.
![Page 48: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/48.jpg)
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.
![Page 49: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/49.jpg)
49
Architectural Styles• Data-centered architectures• Data flow architectures• Call and return architectures• Object-oriented architectures• Layered architectures
![Page 50: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/50.jpg)
50
Data-Centered Architecture
![Page 51: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/51.jpg)
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.
![Page 52: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/52.jpg)
52
Data Flow Architecture
![Page 53: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/53.jpg)
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.
![Page 54: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/54.jpg)
54
Call and Return Architecture
Routine 1.2Routine 1.1 Routine 3.2Routine 3.1
Routine 2 Routine 3Routine 1
Mainprogram
![Page 55: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/55.jpg)
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.
![Page 56: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/56.jpg)
56
Layered Architecture
![Page 57: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/57.jpg)
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.
![Page 58: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/58.jpg)
58
Object Oriented Architecture
• The components of the system encapsulate data and the operations that must be applied to manipulate the data.
![Page 59: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/59.jpg)
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.
![Page 60: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/60.jpg)
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.
![Page 61: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/61.jpg)
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.
![Page 62: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/62.jpg)
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
![Page 63: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/63.jpg)
63
Architectural Context
target system: Security Function
uses
uses peershomeowner
Safehome Product
Internet-based system
surveillance function
sensors
control panel
sensors
uses
![Page 64: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/64.jpg)
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
![Page 65: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/65.jpg)
65
Archetypes
Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])
Controller
Node
communicates with
Detector Indicator
![Page 66: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/66.jpg)
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.
![Page 67: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/67.jpg)
67
Component Structure
SafeHome Executive
External Communication Management
GUI Internet Interface
Function selection
Security Surveillance Home management
Control panel
processing
detector management
alarm processing
![Page 68: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/68.jpg)
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.
![Page 69: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/69.jpg)
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
![Page 70: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/70.jpg)
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.
![Page 71: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/71.jpg)
7171
3.2 Design Engineering
71
![Page 72: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/72.jpg)
7272
Contents
1. Design process and Design quality,
2. Design concepts,
3. Design model.
72
Design Engineering
![Page 73: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/73.jpg)
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
![Page 74: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/74.jpg)
747474
Blue print for real estate
Car blue print
![Page 75: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/75.jpg)
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
![Page 76: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/76.jpg)
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.
![Page 77: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/77.jpg)
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
![Page 78: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/78.jpg)
7878
FURPS
Hey, What is
FURPS?
![Page 79: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/79.jpg)
7979
![Page 80: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/80.jpg)
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
![Page 81: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/81.jpg)
8181
1. Abstractions2. Architecture3. Patterns4. Modularity5. Information Hiding6. Functional Independence7. Refinement8. Re-factoring9. Design Classes
81
![Page 82: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/82.jpg)
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)
![Page 83: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/83.jpg)
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)
![Page 84: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/84.jpg)
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
![Page 85: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/85.jpg)
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
![Page 86: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/86.jpg)
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
![Page 87: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/87.jpg)
8787
The Design Model
Data/Class Design
Architectural Design
Interface Design
Component-level Design
![Page 88: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/88.jpg)
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
![Page 89: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/89.jpg)
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
![Page 90: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/90.jpg)
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
![Page 91: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/91.jpg)
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
![Page 92: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/92.jpg)
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
![Page 93: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/93.jpg)
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
![Page 94: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/94.jpg)
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
![Page 95: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/95.jpg)
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
![Page 96: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/96.jpg)
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
![Page 97: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/97.jpg)
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?
![Page 98: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/98.jpg)
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
![Page 99: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/99.jpg)
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
![Page 100: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/100.jpg)
100100
1. Data structure at programming level
2. Database at application level
3. Data warehouse at business level.
100
![Page 101: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/101.jpg)
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
![Page 102: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/102.jpg)
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
![Page 103: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/103.jpg)
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
![Page 104: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/104.jpg)
104104104
![Page 105: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/105.jpg)
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.
![Page 106: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/106.jpg)
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
![Page 107: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/107.jpg)
107107107
![Page 108: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/108.jpg)
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
![Page 109: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/109.jpg)
109109109
![Page 110: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/110.jpg)
110110110
![Page 111: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/111.jpg)
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
![Page 112: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/112.jpg)
112112112
![Page 113: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/113.jpg)
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
![Page 114: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/114.jpg)
114114114
![Page 115: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/115.jpg)
115115115
![Page 116: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/116.jpg)
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
![Page 117: 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,](https://reader038.vdocument.in/reader038/viewer/2022110103/5697bfbf1a28abf838ca3716/html5/thumbnails/117.jpg)
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