Topic # 05. Software Systems Design Concepts. (Ch. 8) Analysis Model as a Bridge

Transcription

1 Topic # 05 Software Systems Design Concepts (Ch. 8) 1 Analysis Model as a Bridge 2

2 Analysis Model as a Bridge System Description (by a customer) system description List of SW System Specifications (that SW engineer understands) analysis analysis model model design design model model Lists of System Requirements (that customer still understands) System Development by SW technologists and technicians 3 Correspondence between Analysis Models and Design Models Option A ( a new system) Design model = Analysis model specs Option B (a set of small improvements of an old system) Design model = Analysis model specs + small additional design specs Option C (a set of multiple significant improvements of an old system) Design model = analysis model specs + huge number of additional design specs Addit. design Examples of analysis models specs: specs 1) 18 different types of actors (from use cases, from context DFD,...) 2) At least 560 different functions (from COs, from STD, ) Additional design specs 3) At least 11 different types of data structures -- databases, files, arrays, queues, (from Level-0 DFD, ) 4

3 FROM Analysis Model TO Design Model Class objects and processing units Analysis model (DOs, DFDs, ERDs,, STDs, activity diagrams, use cases, etc.) Maps into Design model (architecture, components, data, interfaces) Software modules 5 From Analysis Model to Design Model (details) Design Model scenar io- based element s use-cases - text use-case diagrams activity diagrams swim lane diagrams Model Analysis Model f l ow- or i e nt e d e le me nt s data flow diagrams control-flow diagrams processing narratives In t e rf a c e D e si g n Com p o n e n t - L e v e l D e sig n c l a ss- ba se d element s class diagrams analysis packages CRC models collaboration diagrams be ha v i or a l element s state diagrams sequence diagrams A r c h it e c t ura l D e sig n D a t a / Cla ss D e sig n Design Model 6

4 Design Design - is a meaningful engineering representation of something that must be built (i.e. for engineers and/or developers). In Software Engineering context, Software Design focuses on the following main areas: 1. Architecture architectural design defines the relationships between major structural elements of the software 2. Components component-level design transforms structural elements of the software architecture into a procedural description of software components (based on control specifications, process specifications and state transition diagram). 3. Data data design transforms the information domain model into the particular data structures 4. Interfaces interface design describes how the software communicates within itself,, with other systems, and with users 7 Design Model as a Bridge 8

5 Design Model as a Bridge Analysis Design Development 9 Systems Engineering-Based Approach 10

6 Software Engineer: A Profile Required by Industry A set of composition of skills of software engineer required by industry/businesses, and companies: 25 % - Analytical Skills ability to see things as systems, identify, analyze, and solve problems in an optimal way for a specific organization. (Examples of courses: CS 590, CS 593, CS 690, etc.) 25% - Technical Skills ability to understand how computers, data networks, databases, operating systems, etc. work together, as well as their potentials and limitations (Examples of courses: CS 571, CS 625, etc.) 25 % - Management Skills organization s recourse management, project include management (people and money), risk management, and change management (Examples of courses: CS 591, CS697 or CS698 Adv. Topics on SPM) 25 % - Communication Skills include effective interpersonal communication (written, verbal, visual, electronic, face-to-face conversations, presentations in front of groups), listening, group facilitation skills. (Presentations and communications in classes, course projects, team-working and discussions in your team, etc.) 11 Analytical Skills Analytical Skills include four sets of sub skills that are essential for Software Engineer: 1) Systems Thinking, 2) Organizational Knowledge 3) Problem Identification, and 4) Problem Analyzing and Solving. Systems Thinking involves identifying something as a system, visualizing the system and translating it into abstract terms, and thinking about the characteristics of the specific situation. Systems thinking is very useful in software engineering and development because software applications can be seen as subsystems in larger organizational systems, taking input from, and returning output to, their organizational environments. 12

7 A System and Its Characteristics A System is an inter-related set of components, with an identifiable boundary, working together for some purpose. Any system has nine (9) characteristics: 1) Components - irreducible parts or aggregation of parts 2) Relations (links) - dependence of one subsystem on one or more subsystems 3) Interfaces - points of system-environment and subsystem-subsystem contacts 4) Boundary - a line (probably virtual line) that separates the system from its environment 5) Inputs - whatever a system takes from its environment 6) Output s - whatever a system returns to its environment 7) A Purpose - the overall goal or function of a system 8) An Environment - everything external to a system that interacts with the system 9) Constraint(s) - limit(s) to what a system can expand, shrink, perform, etc. 13 A General Depiction of a System including 9 characteristics Environment System 14

8 Software System Architecture and Views Software architecture is commonly organized in views, which are analogous to the different types of blueprints made in building architecture. Within the ontology*) established by ANSI/IEEE , Views are instances of viewpoints, where a viewpoint exists to describe the architecture in question from the perspective of a given set of stakeholders and their concerns. *) In computer science and information science, An ontology is a formal representation of knowledge as a set of concepts within a domain, and the relationships between those concepts. Examples of SW system views in the IEEE-1471 ontology: 1) Development/structural view 2) Code/module view 3) Functional/logic view 4) Concurrency/process/thread view 5) Physical/deployment view 6) User action/feedback view 7) Data view, etc. 15 System Engineering: A Structural View System System Level (World View) A subsystem Sub.Sys. A Sub.Sys. B Sub.Sys. N... Level of Subsystems (Domains) (Subsystem or Domain View) A component Functions Data Links Inputs Outputs... A detail (attribute) Level of Elements or Components (Element or Component View)... Level of Sub-elements, Details (for ex., attributes) (Detail View) 16

9 Webster Software System: A Structural View (system, subsystems, and component design) System System Level (Webster System) A subsystem GUI Databases Security... Level of Subsystems (Domains) (Databases, GUI, Security, HELP, etc.) A component A detail (attribute) Tables Macros (DOs) Forms Queries Reports... Level of Elements or Components (tables, forms, queries, reports, macros and modules, ) ID FN LN DOB YOA Status... Level of Sub-elements, Details (for ex., attributes) (ID, First Name, Last Name, DOB, YOA, status, ) 17 Software Design: Systems Eng. Context (1/2) Design - is a meaningful engineering representation of something that must be built. In Software Engineering context, Software Design focuses on: 1) Goal. Goal of software design is to produce a model or representation that is - bug free (firmness), - suitable for its intended uses (commodity), and - pleasurable to use (delight). 2) Components + 3) Links = Architecture or Structure architectural design defines the relationships between major structural elements of the software Components component-level design transforms structural elements of the software architecture into a procedural description of software components (based on control specifications, process specifications and state transition diagram). Data Objects (modules) data design transforms the information domain model into the particular data structures 18

10 Software Design: Systems Eng. Context (2/2) 4) Interfaces interface design describes how the software communicates within itself,, with other systems, and with users 5) Inputs legal inputs by user, events (tables) part of STD 6) Outputs legal states, behavior of the system, legal actions (tables) part of STD 7) Environment technical specifications of customer s s environment 8) Constraints limits by customer of system s s functionality and specs, or limits of design process (time, cost, etc.) 9) A boundary separation of an environment (external users) and system (internals users); this is very important for security issues 19 Software Design: Fundamental Concepts 1. Abstraction data, procedure, control 2. Architecture the overall structure of the software 3. Patterns conveys the essence of a proven design solution (best cases, re-usable designs)) 4. Modularity compartmentalization of data and function 5. Information Hiding controlled interfaces 6. Functional single-minded function and low coupling Independence 7. Refinement elaboration of details for all abstractions 8. Re-factoring a reorganization technique that simplifies the design 20

11 1.1. Data Abstraction (abstractive data models not actual objects) door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data object Abstraction - allows designers to simplify a problem and focus on solving a problem without being concerned about irrelevant lower level details Procedural Abstraction (solution algorithms) open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter algorithm Abstraction - allows designers to simplify a problem and focus on solving a problem without being concerned about irrelevant lower level details (en example: procedural abstraction: a subroutine a named sequence of actions and events) 22

12 Examples of algorithms representations Example of algorithm s representation (extreme case = coding) Note: a) Software Engineering is NOT a coding; b) Coding is NOT Software Engineering 24

13 2. Software Architecture (details during next class) The overall structure of the software and the ways in which that structure provides conceptual integrity for a system Structural properties. This aspect of the architectural design representation defines the t components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another. For example, objects are packaged to encapsulate both data and the processing that manipulates the data and interact via the invocation of methods. Extra-functional properties. The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics. Families of related systems (reusable architectural building blocks). The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks. (Details in Ch. 9) 25 System s s Architecture: an example (structural view) System System Level (World View) A subsystem Sub.Sys. A Sub.Sys. B Sub.Sys. N... Level of Subsystems (Domains) (Subsystem or Domain View) A component Functions Data Links Inputs Outputs... A detail (attribute) Level of Elements or Components (Element or Component View)... Level of Sub-elements, Details (for ex., attributes) (Detail View) 26

14 3. Patterns (Reusability of previous designs and design solutions) Design Pattern Template: Pattern name Intent Also-known known-as Motivation Applicability Structure Participants Collaborations Consequences Related patterns describes the essence of the pattern in a short but expressive name n describes the pattern and its functions lists any synonyms for the pattern provides an example of the problem notes specific design situations in which the pattern is applicable describes the classes that are required to implement the pattern describes the responsibilities of the classes that are required to implement the pattern describes how the participants collaborate to carry out their responsibilities describes the design forces that affect the pattern and the potential trade-offs that must be considered when the pattern is implemented cross-references references related design patterns *) Patterns-based SE, patterns-based analysis, patterns-based software development, pattern languages, etc. still a lot of research needed, a lot of Ph.D. dissertations 27 Patterns: Analogy in Construction Engineering (reusability of previous designs and design solutions) 28

15 Patterns: Analogy in Heavy Machinery by Caterpillar: CT660 Truck (reusability of previous designs and design solutions) Caterpillar CT660 (base model) Caterpillar CT660 (vocational truck model) Caterpillar CT660 (low loader model) Caterpillar CT660 (concrete pump model) Caterpillar CT660 (concrete mixer model) 29 3a. Patterns (details) A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. 30

16 3a. Patterns (details) 31 3a. Patterns (details) 32

17 Example of Highly Reusable Base Software System Modular Design (easier to build, easier to change, easier to fix ) easier to build, easier to change, easier to fix... *) 1969, Boeing 747 *) modern cars (standard modules) *) reusable learning objects (modules of online courses) Microsoft Design Center: Industrialization and modular object-oriented software development has theoretically made it easy to tear things down and replace them. 34

18 Modular Approach of Software Systems (easier to build, easier to change, easier to fix ) 35 Modularization vs Decomposition Modularization Decomposition Modularity Decomposition is dividing a system into parts/chunks/modules of relatively uniform size. is the process of breaking down a system into its component parts. 36

19 Software Modularity: Trade-offs What is the "right" number of modules for a specific software design? cost of software module development cost module integration cost optimal number of modules number of modules 37 An example: Libraries (functions, subroutines, etc.) 38

20 Sizing Modules: Two Views One important feature of a module is its length. Longer is not better. What's inside?? MODULE How big is it?? Compilation time is expensive; the longer the module, the longer it takes to compile. Most program changes that require a recompilation of a module are for minor changes, not involving lots of code lines. Try to restrict your modules to 300 lines of code; optimal length: LOC per module If the module needs to be longer, split it into multiple sub-modules, all with a related name. Source: 39 Modular Approach to Learning Content Design: System Level Level of Subsystems (Domains) Level of Components Level of elements 40

21 BTW: Pedagogical Patterns (details) Pedagogical Patterns are high-level patterns that have been recognized in many areas of training and pedagogy such as group work, software design, human computer interaction, education and others. The concept is an extension of pattern languages. In both cases, the patterns seek to foster best practices of teaching. You may think about patterns as some kind of metadata a top-level description of data about data Information Hiding (or, Encapsulation in Programming) clients module controlled interface "secret" algorithm data structure details of external interface resource allocation policy a specific design decision 42

22 Why Information Hiding? leads to encapsulation an an attribute of high quality design results in higher quality software limits the global impact of local design decisions emphasizes communication through well-structured and controlled interfaces reduces the likelihood of side effects discourages the use of global data Advantages of Encapsulation in Programming Large software programs may be split into manageable modules Implementation details are hidden (isolated); as a result, no need ed to waste your time Subprograms and programs become more portable, and, probably, re-usable by external users Development time is shortened due to well-written, written, well-structured, well-tested sub-programs (functions, lists, files, etc.) Functional Independence Functional independence is achieved by developing modules with "single-minded" function and an "aversion" (disliking) to excessive interaction with other modules. Cohesion is an indication of the relative functional strength of a module. A cohesive module performs a single task, requiring little interaction with other components in other parts of a program. Stated simply, a cohesive module should (ideally) do just one thing. One function inside One interface Coupling is an indication of the relative interdependence among modules. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. Many functions inside Multiple different interfaces 44

23 7. Stepwise Refinement Object open walk to door; reach for knob; open door; walk through; close door. Activity Diagram (textual form) repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat Instructions (code) 45 Stepwise Refinement: An example Processing unit function Algorithm Code Processing unit: main function 46

24 FROM Analysis Model TO Design Model (it is actually a refinement process) high analysis model class diagrams analysis packages CRC models collaboration diagrams dat a f low diagrams control-f low diagrams processing narratives use-cases - t ext use-case diagrams act ivit y diagrams swim lane diagrams collaborat ion diagrams st at e diagrams sequence diagrams class diagrams analysis packages CRC models collaboration diagrams dat a f low diagrams cont rol-flow diagrams processing narrat ives state diagrams sequence diagrams Requirement s: const raint s int eroperabilit y t arget s and configurat ion design model low design class realizations subsystems collaboration diagrams refinements to: design class realizat ions subsyst ems collaborat ion diagrams technical interf ace design Navigation design GUI design component diagrams design classes act ivit y diagrams sequence diagrams refinements to: component diagrams design classes act ivit y diagrams sequence diagrams design class realizat ions subsyst ems collaborat ion diagrams component diagrams design classes activity diagrams sequence diagrams deployment diagrams archit ect ure element s int erface element s component -level element s deployment -level element s process dimension 47 An example of Structural View as a refinement process System System Level (Webster System) A subsystem GUI Databases Security... Level of Subsystems (Domains) (Databases, GUI, Security, HELP, etc.) A component Tables Functions (DOs) Forms Queries A detail (attribute) Macros... Level of Elements or Components (tables, forms, queries, reports, macros and modules, ) ID FN LN DOB YOA Status... Level of Sub-elements, Details (for ex., attributes) (ID, First Name, Last Name, DOB, YOA, status, ) 48

25 The Bottom Line: FROM Analysis Model TO Design Model (based on Analysis Model of RE we will be able to create the SW System s s Design Model) Class objects and processing units Analysis model (DOs, DFDs, ERDs,, STDs, activity diagrams, use cases, etc.) Maps into Design model (architecture, components, data, interfaces) Software modules Re-factoring In software engineering, "refactoring" of source code means improving it without changing its overall results, and is sometimes informally referred to as "cleaning it up". Refactoring neither fixes bugs nor adds new functionality, though it might precede either activity. Rather, it improves the understandability of the code, changes its internal structure and design, and removes dead code. These changes are intended to make the code easier to comprehend, more maintainable, and more amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to a program or fixing a bug in it. When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures any other design failure that can be corrected to yield a better design. Examples of re-factoring:??? 50

26 8a. Re-factoring Techniques (not a comprehensive list at all) Techniques that allow for more abstraction: Encapsulate Field - force code to access the field with getter and setter methods Generalize Type - create more general types to allow for more code sharing Replace type-checking code with State/Strategy Replace conditional with polymorphism Techniques for breaking code apart into more logical pieces: Extract Method, to turn part of a larger method into a new method. By breaking down code in smaller pieces, it is more easily understandable. This is also applicable to functions. Extract Class moves part of the code from an existing class into a new class. Techniques for improving names and location of code: Rename Method or - changing the name into a new one that better reveals its purpose Pull Up - in OOP, move to a superclass Push Down - in OOP, move to a subclass Source: b. Re-factoring Tools (in alphabetical order) Add Parameter Change Bidirectional Association to Unidirectional Change Reference to Value Change Unidirectional Association to Bidirectional Change Value to Reference Collapse Hierarchy Consolidate Conditional Expression Consolidate Duplicate Conditional Fragments Convert Dynamic to Static Construction by Gerard M. Davison Convert Static to Dynamic Construction by Gerard M. Davison Decompose Conditional Duplicate Observed Data Eliminate Inter-Entity Bean Communication (Link Only) Encapsulate Collection Encapsulate Downcast Encapsulate Field Extract Class Extract Interface Extract Method Extract Package by Gerard M. Davison Extract Subclass Extract Superclass Form Template Method Hide Delegate Hide Method Hide presentation tier-specific details from the business tier (Link Only) Inline Class Inline Method Inline Temp Introduce A Controller (Link Only) Introduce Assertion Introduce Business Delegate (Link Only) Introduce Explaining Variable Introduce Foreign Method Introduce Local Extension Introduce Null Object Introduce Parameter Object Introduce Synchronizer Token (Link Only) Localize Disparate Logic (Link Only) Merge Session Beans (Link Only) Move Business Logic to Session (Link Only) Move Class by Gerard M. Davison Move Field Move Method Source: Parameterize Method Preserve Whole Object Pull Up Constructor Body Pull Up Field Pull Up Method Push Down Field Push Down Method Reduce Scope of Variable by Mats Henricson Refactor Architecture by Tiers (Link Only) Remove Double Negative by Ashley Frieze and Martin Fowler Remove Middle Man Remove Parameter Remove Setting Method Rename Method Replace Array with Object Replace Assignment with Initialization by Mats Henricson Replace Conditional with Polymorphism Replace Conditional with Visitor by Ivan Mitrovic Replace Constructor with Factory Method Replace Data Value with Object Replace Delegation with Inheritance Replace Error Code with Exception Replace Exception with Test Replace Inheritance with Delegation Replace Iteration with Recursion by Dave Whipp Replace Magic Number with Symbolic Constant Replace Method with Method Object Replace Nested Conditional with Guard Clauses Replace Parameter with Explicit Methods Replace Parameter with Method Replace Record with Data Class Replace Recursion with Iteration by Ivan Mitrovic Replace Static Variable with Parameter by Marian Vittek Replace Subclass with Fields Replace Temp with Query Replace Type Code with Class Replace Type Code with State/Strategy Replace Type Code with Subclasses Reverse Conditional by Bill Murphy and Martin Fowler Self Encapsulate Field Separate Data Access Code (Link Only) Separate Query from Modifier Split Loop by Martin Fowler Split Temporary Variable Substitute Algorithm Use a Connection Pool (Link Only) Wrap entities with session (Link Only) 52

27 Code Re-Factoring Tool: An Example 53 Topic # 05: Design Concepts Homework Assignment 54

28 Topic # 05 Software Design Concepts: Additional Information 55 Software Design Concepts: Davis 95 SW Design Principles 56

29 Software Design Principles = Best Practices (Davis 95) 1) ) The design process should not suffer from limited view = tunnel vision. *) a good designer should consider several (3-5) alternatives and judge them based on given requirements (for ex: technical platforms or programming languages for a new SW system) 2) The design model (s) should be traceable to the analysis model. *) a single element of the Design Model often traces to multiple requirements (for ex: a component of Design Model -- a menu item -- may have one-to to-one one correspondence with Process Specs, Control Specs, DFDs,, State Transition Diagrams, etc.) 3) The design should NOT reinvent the wheel. *) D&D time is short and resources are limited; therefore, use wellw ell-tested design patterns (software modules, learning objects) as often as possible (ex: eventually it will lead to reusable SW components) 57 Software Design Principles (cont.) 4) The design should minimize the intellectual distance between the software and the problem as it exists in the real world. *) SW design solutions should be as close (whenever possible) to the real-world problem domain as possible; (for ex: simulate user -- kids, students, professionals, etc. -- behavior and level of their knowledge and perception;) 5) The design should exhibit uniformity and integration. *) design solutions by multiple teams and designers should look like ONE-person design solutions (one person designed all components of SW) S (for ex: similar interfaces and/or components of multiple Microsoft productsp roducts) 6) The design should be structured to accommodate change. *) upcoming modifications, updates and improvements should NOT lead l to drastic changes or re-design of software system (ex: open-to to-changes design instead of closed-to to-changes design; for ex: downloadable service packs for Win 2003, Office 2003; for ex: Intel cannot replace a chip) 58

30 Software Design Principles (cont.) 7) The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. *) Use messages, progress bars, etc. as often as possible (for ex: System shut-down is in progress, System is experiencing problems with BUTNO blue screen of death ) 8) Well-defined depth of details of design solutions: Design is not coding, coding is not design. *) Do not go too far in depth in design (for ex: design module in procedural languages is about lines of code only) 9) The design MUST BE assessed for quality as it is being created, not after the fact. *) There are special measures to assess design quality. 10) The design should be reviewed to minimize conceptual (semantic) errors. *) Main conceptual elements of design (omissions, ambiguity, inconsistence, useless repetitions, etc.) should be addressed at design stage not coding stage. 59 Software Design: Focus on FURPS Quality Factors Functionality feature set and program capabilities Usability human factors (aesthetics, consistency, documentation) Reliability frequency and severity of failure Performance processing speed, response time, throughput, efficiency Supportability maintainability (extensibility, adaptability, serviceability), testability, compatibility, configurability 60

31 Software Design: Guidelines that are required by Quality A design should exhibit an architecture that (1) has been created using recognizable architectural styles or patterns, (2) is composed of components that exhibit good design characteristics and (3) can be implemented in an evolutionary fashion For smaller systems, design can sometimes be developed linearly. A design should be modular; that is, the software should be logically partitioned into elements ents or subsystems A design should contain distinct representations of data, architecture, interfaces, and components. A design should lead to data structures that are appropriate for the classes to be implemented and are drawn from recognizable data patterns. A design should lead to components that exhibit independent functional characteristics. A design should lead to interfaces that reduce the complexity of connections between components and with the external environment. A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis. A design should be represented using a notation that effectively communicates its meaning. 61 Software Design Engineering Goal of software design is to produce a model or representation that is - bug free (firmness), - suitable for its intended uses (commodity), and - pleasurable to use (delight). Encompasses the set of - principles, - concepts, and - practices that lead to the development of a high quality system or product Design principles establish an overriding philosophy that guides the designer as the work is performed Design concepts must be understood before the mechanics of design practice are applied Software design practices change continuously as new methods, better analysis, and broader understanding evolve 62