Presenter: Dong hyun Park

Transcription

1 Presenter: Dong hyun Park

2 Design as a life cycle activity bonds the requirements to construction Process of breaking down the system into components, defining interfaces and defining components to a level of detail that enables their construction Blueprint of the solution to be implemented Usually not unique

3 DeMarco s terminology: Decomposition design ( D design ): mapping of a system into its component pieces Family Pattern design (FP Design): goal is to establish exploitable commonalities over a family of systems Not covered: User Interface design, Invention design (I design): a conceptualization of a system to satisfy discovered needs and constraints

4 Design key concepts Goals Constraints Alternatives Representations Solutions

5 Software design is bounded to: Requirement analysis Construction (coding and unit testing) Integration and qualification testing Linear or Incremental life cycle models

6 Software architectural design Software detailed design

7 Definition of software architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and principles guiding its design and evolution. Reuse of generic design knowledge: Architectural Styles Design Patterns Product Lines

8 Key purpose of software architecture is communication among stakeholders Design View: A collection of models that represent an aspect of an entire system. Represent a partial aspect of software architecture that shows specific properties of a software system Overall organization at o of an SDD is composed posedof anumber of design views each of which contains a subset of the various attributes describing design entities View model by IEEE: Decomposition, Dependency, Interface, detailed description 4+1 view model by RUP: Logical, Implementation, Process,Deployment,Use case

9 Views can be classified into 3 categories called Viewtypes: Module viewtype Component and connector viewtype Allocation viewtype Software architecture is a multifaceted artifact produced by the design process and composed of a set of relatively independent and orthogonal views

10 A pattern is a common solution to a common problem in a given context Goal is to codify and document recurring solutions to typical problems Attributes to ensure transferability: Pattern name The context in which the pattern may apply Example illustrating need Essence of the general problem Underlying solution Implementation guidelines Related patterns Advantages and disadvantages

11 Pattern Classification based on scope and level of abstraction: act Architectural Styles Design Patterns Coding Idioms ( part of software construction not explained in this paper)

12 An architectural style expresses a fundamental structural organization schema for software systems. It provides a rich set of predefined subsystems, specifies their responsibilities, and includes rules and guideline for organizing the relationship between them Major Architectural Styles: General structure Distributed systems Interactive ti systems Adaptable systems Other Styles Choice depends on quality attributes that must be satisfied. Heterogeneous Choice depends on quality attributes that must be satisfied. Heterogeneous styles are possible.

13 Gamma et al. : Creational patterns Structural patterns Behavioral patterns Buschmann et al. : Structural decomposition patterns Organization of work patterns Access control patterns Management patterns Communication patterns

14 Based on software product lines and software components Software production line : A collection of systems sharing a managed set of features constructed from a common set of core software asset Building a common set of software assets involves identifying the key commonalities encountered among the various members of the possible family of product done through hdomain analysis as well as accounting for their possible variability done by identifying and defining reusable and customizable components In an object oriented context, a related notion is that of framework, a partially complete software subsystem that can be extended by instantiating specific plug ins or hot spots

15 Software Quality: The totality of features and characteristics of a software product or service that bear on its ability to satisfy stated or implied needs Properties of Software Quality Functionality Usability Efficiency Maintainability i portability

16 4.1 Design Quality Attributes Run time qualities Development time qualities Impact of architectural choices Conceptual integrity which concerns the architecture s intrinsic quality : architecture reflects one single set of design ideas leading to simplicity, consistency and elegance 4.2 Measures (quantitative estimates) Depends on selected design approach Function oriented oriented (structured) measures Objected oriented measures 4.3 Quality Analysis and Evaluation Tools Quality attributes are hard to quantify Software design reviews Simulation and prototyping

17 Budgen categorization: Black box notation : external properties of the elements of a design model White box notation : describing some aspect of the detailed realization of a design element Alternative categorization: Structural/Static properties Behavioral/dynamic i properties 5.1 A selection of Design Notations (UML) Classand and object diagrams Component diagrams Deployment diagrams Structure charts Structure (Jackson) diagrams

18 52B 5.2 Behavioral ld Descriptions (Dynamic view) Activity diagrams Interaction i diagrams : sequence and collaboration diagrams Data flow diagrams State transition diagrams and statechart diagrams Pseudo code and program design languages (PDLs)

19 Coherency of the design documentation depends on many aspects: stakeholders, software development methods Key ypractice is selection of an appropriate p set of views which satisfies different stakeholders needs Project manager: detailed allocation views Developer: detailed module and component andconnector views

20 View documentation ti also involves describing interfaces of the element from that view A key characteristic of any interface specification : must be two way which means what the element provides and what it requires Another key idea: design should be presented and documented in a rational way: the rationale behind the key decisions should also recorded ex. The design alternatives that were considered and rejected should be described

21 6.1 General Strategies and Enabling Techniques Software design strategies can be described in terms of enabling techniques : independent of specific software development method Abstraction ti Coupling and cohesion Divide and conquer Information hiding and encapsulation Sufficiency

22 62F 6.2 Function oriented i t d(structured) t Design Divide and conquer approach toward identifying major system function in a top down approach. Structured analysis produces DFDs of the various system functions together with associated process descriptions, that is, descriptions of the processing performed by each subtask, usually using informal Pseudocode. Entity relationship diagrams describing the data stores can also be used. Key strategies to help derive a software architecture from a DFD Transaction analysis: triggers Transformation analysis : identifying the central transform, structure chart Key concept of structured design are those of coupling and cohesion: restrict coupling to normal types: data, stamp, control coupling. Avoid common and contest coupling

23 Additional Heuristics to improve the quality of resulting design Fan in/fan out: high / low or moderate ( 5 7 7max) Decision splitting (avoid separating them into files) Balanced systems: top level modules deal with logical and abstract data independent d of the implementation format

24 6.3 Object oriented Design Object based (no inheritance or polymorphism) Vs object oriented design OO design (solution domain) Vs requirement analysis ( problem domain) Class diagrams Vs Integration diagrams (sequence or elaboration diagrams) 6.4 Data structured oriented Design (Jackson Structured Programming) Emphasis is on the data that a program manipulates rather than the functions it performs Motivated by stability in data rather then functions that need to be performed Restricted to the design of data processing programs using sequential ( batch style) files and processes Jackson System Development (JSD) : approach similar il to OOD to address more complex interacting processes

25 Comprehensive overview which does not get the reader lost Gets the reader motivated to read the following design papers Lack of references to sources that expand on topics

26