10조 이호진 이지 호

Transcription

1 10 조 이호진 이지호

2

3

4 According to the IEEE definition, design is.. The process of defining the architecture, components, interfaces, and other characteristics of a system or component

5 1. INTRODUCTION D design-decomposition design, a mapping of a system into its components pieces FP design-family pattern design, whose goal is to establish s exploitable e commonalities over a family of systems

6

7 2.1. General Design Concepts a person who designed the crossword puzzle a person solving a crossword puzzle ( O ) ( X )

8 2.1. General Design Concepts Goal- a means of transportation Constrainttype of engine Five key concepts Goals Constraints Alternativesti Representations Solutions Design of a modern car Alternativeengineer (using their experiences) Representation- blueprint of car frame Solutioncar construction

9 Software Design Context Software Software development life cycle Software Software Software requirements coding and integration and analysis testing qualification the intended use of the system to be developed is analyzed and the requirements are specified the software units identified by the software design activity are developed and t e s t e d the various software units identified during design are combined together and tested

10 Software Design Context Life cycle model Linear model - process runs linearly through the activities ex) the waterfall model Incremental model - process runs iteratively through the activities ex) the spiral model waterfall model spiral model

11 2.3. Software Design Process Software architectural design - how the system is broken down and organized into components the software architecture Software detailed design - the specific behavior of the various components identified by the software architecture

12

13 IEEE Standard 1471 defines software architecture as follows The fundamental organization of a system embodied d in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution

14 3.1. Architectural Structures and Views software architecture analysts managers stakeholder testers Different high-levelh l facets of a software design should be described and documented implementers These facets are called Views

15 AView View represents a partial aspects of a software architecture that shows specific properties of a software system It is a collection of models that represent one aspect of an entire system

16 3.1. Architectural Structures and Views A well-known approach is Kruchten s 4+1 view model Logical view how the functional requirements are satisfied. Implementation view how the design is broken down into implementation units. Process view issues related to concurrency and ddistribution tib ti Deployment view how the runtime units and components are distributed ib t d onto the various processing nodes Use case ie ties together the other Use-case view ties together the other views, illustrating how they work together

17 3.1. Architectural Structures and Views Views can be classified into three categories, called Viewtype Module viewtype classes, collections of classes, and layers Component and connector viewtype - processes, objects, clients, servers, and data stores Allocation viewtype hardware, file system, and development team

18 3.2. Macro/Microarchitectural Patterns :Architectural Styles vs Design Patterns The key goal of patterns is to describe to codify and document, In order to make it transferable, a system of patterns is introduced as following below The name of the pattern The context, the key situations in which the pattern may apply An example illustrating the need for the pattern The general problem that the pattern tries to solve The solution underlying the pattern, both the structure of the pattern s elements and their run time behavior Guidelines for the pattern s implementation

19 3.2. Macro/Microarchitectural Patterns :Architectural Styles vs Design Patterns Patterns can be classfied into three key major categories (depending on their scope and level of abstraction) Architectural Styles General structure ex) layers, pp pipes, filters, blackboard Distributed systems ex) client server, three tiers, broker Interactive systems ex) model view controller, presentation abstraction control Adaptable systems ex) microkernel, reection Other styles ex) batch, interpreters, process control, rule based

20 3.2. Macro/Microarchitectural Patterns :Architectural Styles vs Design Patterns Design Patterns (Gamma et al) Creational pattern deal with the creation of objects Ex) builder,factory,prototype,singleton Structural patterns deal with composition of objects Ex) adapter, bridge, composite, decorator Behavioral patterns how objects interact Ex) command, interpreter, iterator, mediator, memento, observer,state, template, visitor

21 3.2. Macro/Microarchitectural Patterns :Architectural Styles vs Design Patterns Design Patterns (Buschmann et al) Structural t decomposition patterns decomposition of subsystems and complex components into cooperating parts Organization of work patterns how components collaborate together to solve a complex problem Access control patterns guards and control access to services and components Management patterns homogeneous collections of objects, services and components in their entirety Communication patterns help organize communication between components

22 Design of Families of Systems and Frameworks An important goal of software design has always been to allow for the reuse of software elements Recent approach toward that goal Software product line a collection of systems sharing a managed set of features constructed from a common set of core software assets Product line a family of systems and is based on and populated with software components

23

24 software quality defined as... The totality of features and characteristics of a software product or service that bear on its ability to satisfy stated or implied needs

25 According to ISO/IEC Standard software quality can be characterized by the following six properties Efficiency Functionality Functionality Reliability Usability Maintainability Reliability Efficiency Maintainability Portability Portability Usability

26 4.1. Design Quality Attributes Run-time qualities observable only while the system is functioning ex) functionality, usability, performance, reliability, availability, security Development-time qualities impact on the work of fthe development and maintenance teams, but not directly observable at run time. ex) integrability, modifiability, portability, reusability, testability

27 4.1. Design Quality Attributes Appropriate architectural choices can modifiability reusability performance can t functionality usability

28 4.1. Design Quality Attributes Can I improve the rating for that attribute by making structural changes? Kazman and Bass

29 4.1. Design Quality Attributes Design review approach, identify the key desirable properties of a design as being the following well structured simple efficient i adequate

30 4.1. Design Quality Attributes Design review approach, identify the key desirable properties of a design as being the following flexible practical implementable standardized

31 4.2. Measures Function-oriented (structured) measures the design s s structure, obtained through functional decomposition, is represented as a structure chart on which measures can be computed Object-oriented measures the design structure is represented as class diagrams, on which measures can be computed

32 4.3. Quality Analysis and Evaluation Tools Software design reviews informal or semiformal, often group-based, techniques used to verify the quality of design artifacts t Design esg reviews e Requirements tracing

33 4.3. Quality Analysis and Evaluation Tools Simulation and prototyping dynamic techniques used to evaluate a design Reliability analysis Feasibility prototyping o

34

35 5.1. A Selection of Design Notations Static view Class and diagrams used to represent a set of classes(and objects) and their relationships. used in object-oriented oriented design Component diagrams used to model the static implementation view of a system Ex) to document the module structure

36 5.1. A Selection of Design Notations Static view Deployment diagrams used to model the static deployment view of a system. Typically, such diagrams can be used to represent distribution aspects ex) to model embedded, client/server or distributed systems Structure charts used to describe the calling structure of programs. Such diagrams are at the heart of the structured design approach

37 5.1. A Selection of Design Notations Static view Structure (Jackson) diagrams used to describe the data structures manipulated by a program

38 5.1. A Selection of Design Notations Dynamic view Activity diagrams used to show the control flow activity to activity. These diagrams are related to the older owcharts Interaction diagrams used to show the interactions ti among a group of objects Data flow diagrams used to show the data flow Data flow diagrams used to show the data flow among a set of processes

39 5.1. A Selection of Design Notations Dynamic view State transition diagrams and statechart diagrams used to show the control flow from state t to state t in a state t machine Pseudocode and program design languages used to describe, generally at the detailed design stage, the behavior of a procedure or method

40 5.2. Design Documentation How these various notations can be combined to obtain a coherent design document?

41 5.2. Design Documentation manager developer tester Integrator customer user Different needs The selection of an appropriate set of views strongly depends on the stakeholders

42

43 6.1.General Strategies and Enabling Techniques Abstraction - the process of forgetting information so that things that are different can be treated as if they were the same Divide and conquer - technique that solves a complex problem by dividing it into two or more simpler problems Divide and conquer

44 6.1.General Strategies and Enabling Techniques Coupling and cohesion Coupling - the strength of the relationships between software components A good organization structure has strong cohesion within groups and weak coupling between groups Cohesion - how the elements making up a component are related

45 6.1.General Strategies and Enabling Techniques Information hiding and encapsulation Information hiding - Every module is characterized by its knowledge of a design decision which it hides from all others Encapsulation -The grouping of related ideas into one unit, which can thereafter be referred to by a single name the separation of interface and implementation Hiding

46 6.1.General Strategies and Enabling Techniques Sufficiency, i completeness, primitiveness iti these notions pertain to the idea that t a software component should capture all the important characteristics ti of an abstraction ti needed d to interact t with it and nothing more

47 Structured Design is.. One of the early software design paradigms, in which decomposition centers on identifying the major systems functions

48 6.2. Function-oriented oriented (Structured) Design Transaction analysis Transformation analysis Two key strategies that have been proposed to help derive a software architecture, represented as a structure chart, from a DFD

49 6.2. Function-oriented oriented (Structured) Design Transaction analysis, Transformation analysis Transaction is characterized Identify the central transform - by some event in the the portion of the DFD that environment that generates contains the essential a stimulus to the system, functions of the system and is which in turn triggers some independent of the particular system s activity that implementation of the input produces a response having and output an effect upon the event

50 6.2. Function-oriented oriented (Structured) Design a1 a2 a3 a2 a2 a3 e1 a2 e1 e2 a1 e2 Data Flow Diagram (DFD) Figure 1.using transform analysis to derive a structure chart from a DFD First cut structure chart

51 Key concepts of structured design is.. Coupling and Cohesion, which characterize a design of good quality

52 6.2. Function-oriented oriented (Structured) Design Good design Good design should restrict the coupling between modules to normal types of coupling(ex. data, stamp, control coupling, data coupling,) Good design should avoid other pathological forms of coupling(ex. Common and content coupling) Good design should give preference to modules having high cohesion

53 6.2. Function-oriented oriented (Structured) Design Additional heuristics have been suggested to improve the quality of the design Fan-in/fan-out, Decision splitting, Balanced systems

54 6.2. Function-oriented oriented (Structured) Design Fan-in/fan-out, Decision splitting, Balanced systems A high fan-in is considered good A low to moderate fanout is generally preferable Decision splits should be avoided, when the recognition of a condition and the execution of the associated action are not kept within the same module Balanced system is preferable, when the toplevel modules deal with logical and abstract data.(clean, independent of implementation format)

55 Function-oriented oriented (Structured) )Design Structured design s limit Structured design, being one of the first well- described and well-known design methods, made important t contributions ti to the filed of software design However, with emergence of object-oriented languages and programming, it started to reach its limits

56 The notion of object is.. This is intimately tied to the notions of data abstraction, encapsulation, and abstract data type (ADT) Object - created/destroyed, has a unique identity, a state and exhibits some well-defined behavior Objects are generally organized into classes

57 6.3. Object-oriented Design Early approaches Later approaches on OOD Objects were mostly similar to entities in entity-relationship modeling. Inheritance was not used. These are said to be object-based Inheritance and polymorphism pay a key role There are said to be object-oriented

58 6.3. Object-oriented Design OO design methods OO design models OO design methods aim at developing software systems composed of interacting objects that are highly modular and, thus, easy to modify, extend, and maintain OO design models address structural aspects(ex. Classes and objects, their relationships and their grouping as well as behavior ones) objects behavior and interactions

59 6.3. Object-oriented Design The notations used for documenting OO models Diagrammatic Textual Mathematical

60 6.3. Object-oriented Design Structured method OO analysis method Structured design OO design method

61 Unified Modeling Language (UML) is.. UML, evolving from the integration of a number of OO methods, provides a wide variety of notations for OO analysis and design. UML includes various notations (ex. real-time modeling, formal specification using OCL)

62 Unified Process(UP) is.. UP consists of four phases(inception, elaboration, construction, transition). Each phases, delimited by an appropriate milestone, consists it of one or more iterations. ti Each iteration generally results in an executable release and involves a number of core workows (ex. requirements, analysis, design, implementation and test)

63 6.3. Object-oriented Design UML versus UP UML is simply a set of notations, neutral with respect to any specific design method. Unified Process(UP), elaborated by the same people who developed UML, does define a software development process that incorporates OO analysis and design.

64 6.3. Object-oriented Design The key input to the design workflow It is a collection of use cases that describe the functional requirements (a use case is a description of a set of sequences of actions that a system performs to yield an observable result)

65 The output of the design workflow is.. It is a design model consisting of classes and their collaborations, possibly organized into packages and subsystems, that provide the intended behavior while satisfying the non-functional requirements.

66 6.3. Object-oriented Design Class diagram and analysis-model It models a set of classes and their relationships. (ex. association, aggregation, inheritance, dependency..) During design, class diagrams play a central role as they identify the major kinds of objects that will cooperate to produce the system behavior. It also contains class diagrams. Although these latter classes can provide a starting point for identifying some of the design model classes, there is not necessarily a direct correspondence between the two sets of classes.

67 6.3. Object-oriented Design The example of the UML class diagram BankAccount balance balance a () transferto() deposit() withdraw() owns Customer Figure 2.A UML class diagram for bank accounts SavingAccount CheckingAccount

68 6.3. Object-oriented Design Interaction diagrams How objects from the various classes collaborate to provide the desired system behavior is described using Interaction diagrams Interaction diagrams come in two flavors (ex. sequence diagrams, collaboration diagrams)

69 6.3. Object-oriented Design The example of a simple collaboration diagram 1:b:=balance() transferto(b2,amout) 3:[b<=amount] deposit (amount) Fi 3 A UML ll b ti di f Figure 3. A UML collaboration diagram for a transferto operation

70 6.3. Object-oriented Design Statechart diagrams interaction diagrams do not describe the behavior of a specific class of objects in reaction to all possible events. Such class specific behavior can be described using a state chart diagram, a generalized form of state transition diagram It describes an objects behavior from an internal viewpoint

71 6.3. Object-oriented Design The early OO methods The early OO methods focused mostly on data abstraction and ADTs, viewing gprimarily objects through their components and static structural relationships, an approach called data-driven driven design.

72 6.3. Object-oriented Design Responsibility-driven design UP design approach, as do many modern OOD methods, instead focuses on properly identifying and assigning responsibilities to classes and objects, and approach named responsibility-driven Responsibility-driven design generally improves encapsulation, produces a less complex design with improved coupling and cohesion, and tends to produce systems in which the overall control is better organized and balanced, thus more modular

73 6.3. Object-oriented Design The growth of the OO approach The growth of the OO approach over the last two decades has been phenomenal (ex. The design patterns movements..) For lack of space, several aspects related with OO design have not been addressed (ex. persistence, error handling, component-based design..)

74 Datastructure Data-structure structure-oriented Design Approach in which the emphasis is on the data that a program manipulates rather than the functions it performs

75 Datastructure Data-structure structure-oriented Design In JSP Designer first tdescribes the input and output tdata Develops the program s control structure by establishing an appropriate correspondence between the input and output data structure diagrams Once the program control structure is properly defined, appropriate p program actions and conditions are then added to obtain the final program

76

77 7. Conclusion Software design is a rich and still evolving field