487-390 Main 487-371 Rice 1
487-390 Main 487-371 Rice 2
3
• Data Design – Transform the information domain (created in analysis) into Data structures. • Architectural Design: – Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal • Interfaces Design - How the system interfaces: – With itself (procedure calls) – With other systems – With users (Screens) • Components Design – Structural elements into procedural description 4
• Abstraction - Each step of the SW process refines the solution and removes levels of abstraction: – High level – user and environment – Low levels – code 5
• Describes: – the structure of a program: • how the modules interact – the structure of the data. 6
• Organization of the modules within a program – Does not show sequence of processes – It shows how modules call each other • Hierarchy of Control • TreeLike Notation – Represents hierarchical control for call and return architecture (example Pressman Page 347) 7
• A good module has functional independence. • It is achieved by developing modules with "single-minded" function • Functional Independence is measured by looking at the cohesion and coupling of the modules. 8
• Each module should have a central theme or purpose. – Should be able to describe a cohesive module using a sentence with one subject and one verb • High cohesion is good. Low cohesion is to be avoided. 9
• Coincidentally cohesive (worst): – module performs tasks that are related loosely or maybe not at all. – Example: divide the monolithic program into modules using a ruler • Logically Cohesive (low): – Logically related tasks in one module – Example: A module that does all errors processing tasks. • Temporal cohesion (low): – tasks of a module are related because they must be executed in the same time span . – Example: Clean up tasks at the end of processing 10
• Communicational cohesion (moderate): – all processing elements concentrate on one area of a data structure. – Update the record in the database and add to audit trial. – module performs one distinct task. – Example: a Procedure that computes the shipping cost of an order. 11
• Refers to the degree of interconnectedness between modules • Minimize coupling to reduce the ripple effect when changes are made. • The goal is to reduce connection paths between modules. • High coupling limits reuse. • lowest possible coupling 12
• Data coupling (low): – Only simple data items are passed • Stamp coupling (low): – A structure is passed, even though only a portion of the data items are needed. • Control coupling (moderate): – a "control flag", variable that controls decisions in a subordinate or super-ordinate module is passed. • External coupling (high): – modules are tied to an environment. I/O ties modules to a specific device, formats and communication protocols. 13
• Common coupling (high) – modules reference a global data area. • Content coupling (highest): – when one module makes use of data or control information maintained within the boundary of another module. • This should always be avoided 14
• Data Design – Transform the information domain (created in analysis) into Data structures. • Architectural Design: – Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal • Interfaces Design - How the system interfaces: – With itself (procedure calls) – With other systems – With users (Screens) • Components Design – Structural elements into procedural description 15
Chapter 14 16
• To View and Evaluate the system as a whole before moving to component design. – Blueprint of a house • 1 st the foot print of the house is designed • Then plumping and electrical plans are drawn. 17
• Data Design – Transforms data elements in the Requirement Specification (ERD, data dictionary) into data structures. – Represent the data component of the architecture • Architectural Design – Define a family of system in terms of a pattern of structural organization • i.e. Ranch vs. Victorian House. – Focuses on the structure of the SW components • Properties and • interactions 18
Approaches to Selecting an Architectural Design for a system • Analyze the needs of the system – Requirements, – Constraints, and the – Environment • Evaluate different architectures – Pick the best • Map requirements of your system into the selected architecture. 19
• Is a pattern for construction: – Should guide the builder – Ranch style, Victorian Style will give you a general idea on the architecture of the system – Each style encompasses a set of Categories 20
• They Define the Architectural Style: – Components that perform a function • Database, simple computational modules, clients, servers and filters. – Connectors, enable communications • Define how the components communicate, coordinate and cooperate – Call, event broadcasting, pipes – Constraints • Define how the system can be integrated – Semantic Models • Specify how to determine a system’s overall properties from the properties of its parts. 21
• Data Flow Systems: (Figure Page 373 ) – Batch Sequential – Pipes and Filters • Call-and-Return systems – Main program and sub-programs – Object Oriented Systems – Hierarchical layers 22
• Independent Components: – Communication Processes – Event Systems • Virtual Machines – Interpreters – Rule based Systems • Data-Centered Systems (Figure on page 372): – Databases – HTML Systems 23
• Components : Filters – Each Filter transforms the data • Connectors : Pipes – Transmit data from one filter to the next • Constraints : – Each Filter works independently – Each filter expects Input and should produce Output. • Page 373 for Model 24
• Is a Pipes and Filters model with ONE flow • Page 373 for Model 25
• Components : Main and Sub-Components • Communication : Main calls sub-programs • Constraints : Main act as a Driver Main Sub1 Sub2 26
• Components: Database elements (tables, queries, etc.) • Communication: Relationships • Constraints : Client request info from Server 27
• Data Design – Transform the information domain (created in analysis) into Data structures. • Architectural Design: – Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal • Interfaces Design – (Chapter 13) How the system interfaces: – With itself (procedure calls) – With other systems – With users (Screens) • Components Design – Structural elements into procedural description 28
• User Model – Depicts the profile of end users – Should be related to user characteristics: • Age • Gender • Education • Special Needs – Types of users: • Knowledgeable frequent • Knowledgeable infrequent • Never seen a computer before 29
• Design Issues: – Response Time – Help Facility – Error Messages • Expressed in user terms • Extended help for action • Provide more info on sequences • Non-Judgmental – Command Labeling • menus 30
• Guidelines – Be Consistent – Easy to use screens - Be SIMPLE – Offer Meaningful feedback – Permit easy reversal of most actions – Reduce the amount of information that must be memorized • Use Pull-down-menus – Keep help at all levels 31
• Guidelines – Meaningful Titles – Get user feedback • Listen to users • Ask for suggestions • Prototype and get feedback again and again until the user says “This is the best” • Don’t be too technical 32
• Data Design – Transform the information domain (created in analysis) into Data structures. • Architectural Design: – Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal • Interfaces Design - How the system interfaces: – With itself (procedure calls) – With other systems – With users (Screens) • Components Level Design (Chapter 16) – Structural elements into procedural description 33
• Also known as Procedural Design • The intent is to translate the design model into code like language. • Represent the design at a level of abstraction that is close to Code DATA PROCEDURAL ARCHITECTURE DESIGN INTERFACES 34
• Establish the algorithmic detail required to: – Manipulate data structures – Define components interfaces – Implement the processing algorithms for each component. • Its an opportunity to verify your design correctness 35
• Graphical – Flowchart (Page 425) • Tabular Design Notation – Decision Table (Page 429) • Text – Program Design Language “Pseudo-Code” (Page 431) 36
Recommend
More recommend
