1 / 58

Design

Design. ECE 417/617: Elements of Software Engineering. Stan Birchfield Clemson University. From modeling to design. Steps: Analysis and modeling Design Construction (code generation and testing). Design involves making the analysis model more specific, to facilitate construction.

kellsie
Download Presentation

Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Design ECE 417/617:Elements of Software Engineering Stan Birchfield Clemson University

  2. From modeling to design Steps: • Analysis and modeling • Design • Construction (code generation and testing) Design involves making the analysis model more specific, to facilitate construction. Goal of design is quality.

  3. FURPS Quality software is • Functional – capabilities of program • Usable – human factors, aesthetics • Reliable – frequency and severity of failure • Performance – response time, speed • Supportable – is the code maintainable, extensible, testable, configurable, easy to install, etc. (Developed by Hewlett-Packard in 1980s)

  4. Basic design principles • Design is iterative: • Architecture is refined over time by successively filling in details • Refinement is a process of elaboration • Results in hierarchical model • A good design exhibits • abstraction – details are provided in lower levels • modularity – divide-and-conquer via smaller independent components • refactoring – internal structure of software is improved without affecting external behavior

  5. Design model Design model has three aspects: • Architectural design • Component-level (data) design • Interface design We will consider these in turn, with UI covered in a separate lecture.

  6. Architectural Design

  7. Architectural design • Architecture is a high-level representation of the S/W with the major components identified • Architectural styles are templates, e.g., • Data-centered • Data-flow • Call and return • Object-oriented • Layered • Architectural patterns define specific approach for handling some behavioral characteristic of system, e.g., • concurrency: use O/S features or provide task scheduler • persistence: storage and retrieval of data • distribution: communication of components with one another. Most common is broker – acts as middle man between client and server (CORBA). Style is like “Cape cod, A-frame”. Pattern is like “kitchen”.

  8. Architectural Styles • Data-centered – subsystems interact through single repository • Model / View / Controller • Call and return (Client / Server) • Layered (three-tier, four-tier) • Data-flow (pipe and filter)

  9. Layers and Partitions • Layer – group of related subsystems • Layer knows about layers below it, but not layers above it • Top layer: no one else knows about it • Closed architecture – can only access layer immediately below • Open architecture – can access any layer below • Partition – peer subsystems, each with different responsibilities

  10. Application Object Presentation Format CORBA Session Connection Transport Socket Message TCP/IP Network Packet DataLink Physical Ethernet Wire Frame Bit Hierarchical decomposition Level of abstraction Example: Open Systems Interconnection (OSI)

  11. Mapping DFD into architecture • Transform mapping • transform flow always exists; represents information flow within system; incoming flow passes through transform center, leads to outgoing flow • To map DFD with transform flow characteristics into specific architectural style, • review model • refine models • determine whether transform or transaction characteristics • isolate transform center • perform first and second level factoring • refine • Transaction mapping • transaction flow occurs when one input gives rise to several outputs; transaction triggers data flow along one of many paths • To map DFD with transaction flow characteristics, • review model • refine models • determine whether transform or transaction characteristics • isolate transaction center • map to transform branch • factor and refine

  12. Model / View / Controller (MVC) • MVC: • Model subsystems maintain domain knowledge • View subsystems display it to the user • Controller subsystems manage sequence of interactions with user • M doesn’t depend upon V or C • Changes propagated via subscribe/notify protocol, using Observer design pattern • Well-suited for interactive systems

  13. initiator Controller 1 repository * Model 1 notifier subscriber View * MVC Details

  14. MVC Example

  15. MVC Example Details 2:enterNewFileName(file,newName) 3:setName(newName) :Controller :Model 1:subscribeToFileEvents(file) 5:getName() :InfoView 4:notifySubscribedViews(file) 4:notifySubscribedViews(file) :FolderView 1:subscribeToFileEvents(file) 5:getName()

  16. GUI-Based Programming

  17. Paradigms Compared Application callbacks draw output Widgets Application output input input The User Traditional command-line GUI-based

  18. Event/Message loop

  19. Event loop – pseudocode int main() { return WinMain(); } WinMain() { while (1) { // loop forever, waiting for an event if (event_exists) { //there is an event, figure out what to do if (event == keydown_a) display(‘user pressed the A key’); else if (event == window_resize) display(‘window resized’); else if (event == repaint) display(‘need to repaint window’); else if (event == keydown_escape) exit_program(); } } }

  20. Event loop – WinMain int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, char * cmdParam, int cmdShow) { char className [] = "Winnie"; WinClass winClass (WindowProcedure, className, hInst); winClass.Register (); WinMaker win ("Hello Windows!", className, hInst); win.Show (cmdShow); MSG msg; int status; while ((status = ::GetMessage (& msg, 0, 0, 0)) != 0) { if (status == -1) return -1; ::DispatchMessage (& msg); } return msg.wParam; }

  21. Event loop – WindowProc LRESULT CALLBACK WindowProcedure (HWND hwnd, unsigned int message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_DESTROY: ::PostQuitMessage (0); return 0; } return ::DefWindowProc (hwnd, message, wParam, lParam ); }

  22. Event loop (cont.) int WINAPI WinMain(HINSTANCE hinstance, HINSTANCE hprev, PSTR cmdline, int ishow) { HWND hwnd; MSG msg; //initialization code goes here while(1) { // Get message(s) if there is one if(PeekMessage(&msg,hwnd,0,0,PM_REMOVE)) { if(msg.message == WM_QUIT) break; TranslateMessage(&msg); DispatchMessage(&msg); //this calls the CALLBACK function WinProc() } else { DrawScene(); //display the OpenGL/DirectX scene } } }

  23. Event loop (cont.) LRESULT CALLBACK WinProc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) { PAINTSTRUCT ps; // Depending on the message -- we'll do different stuff switch(message) { case WM_PAINT: Draw(); return 0; // ESC will quit program case WM_KEYDOWN: //user pressed a key if(GetAsyncKeyState(VK_ESCAPE)) //it was the escape key PostQuitMessage(0); //quit program return 0; case WM_DESTROY: //windows wants the program to die case WM_CLOSE: //or the user closed the window PostQuitMessage(0); //quit program return 0; } return DefWindowProc(hwnd, message, wparam, lparam); }

  24. GUI Concepts • Widget – graphic object with functionality; e.g., button, toolbar, ... • Window – holds widgets • Child/parent – relationships between windows • Event / message – how windows communicate

  25. Anatomy of a Window title bar menu toolbar client area status bar

  26. Microsoft Windows Programming • History: • Win32 API: core library written in C • MFC: C++ wrappers around most common Win32 API functions • Lots of macros • Lots of legacy code • Not free, not portable • But it works (generally speaking)

  27. Analyzing architectural designs Two approaches developed by SEI: • Architecture trade-off analysis method (ATAM) • Collect scenarios and requirements • Evaluate quality attributes and their sensitivity • Critique candidate architectures • Scenario-based architectural analysis (SAAM) • Uses scenarios to analyze architectures with respect to quality attributes Quality attributes: reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability

  28. Component-level Design

  29. Component-level design • Occurs after the first iteration of architectural design • Goal: translate the design model into operational software • Component is set of collaborating classes • Designing components • OCL • flow chart • tabular design notation Decision table has four quadrants specifying conditions and actions, as well as rules for both • PDL (pseudocode)

  30. Decomposition System ... Subsystem1 SubsystemN ... ... Class1a Class1n ClassNa ClassNn

  31. Coupling and cohesion • Coupling -- # of dependencies between subsystems • Cohesion -- # of dependencies within subsystem • Goal: low coupling, high cohesion • 7 +/- 2 rule – keep number of concepts at any given layer of abstraction bounded

  32. Additional design principles • Single responsibility (SRP)A class should have only one reason to change • Open-closed (OCP) Software entities should be open for extension but closed for modification (achieved via inheritance) • Liskov substitution (LSP)Subclasses should be substitutable for their base classes • Dependency inversion (DIP)Abstractions should not depend upon details • Interface segregation (ISP)Many client-specific interfaces are better than one general purpose interface • Release reuse equivalency (REP)Granule of reuse is granule of release • Common closure (CCP)Classes that change together belong together • Common reuse (CRP)Classes in a package are reused together

  33. Data structures and flow • Software system is composed of • data structures, and • data flow • Which is more important? “Show me your code and conceal your data structures, and I shall continue to by mystified. Show me your data structures and I won’t usually need your code. It will be obvious.” – Fred Brooks

  34. What is a Design Pattern? • A design pattern • abstracts a recurring design structure • comprises class and/or object • dependencies, • structures, • interactions, or • conventions • distills design experience

  35. Re-use • Code re-use • Don’t reinvent the wheel • Requires clean, elegant, understandable, general, stable code • leverage previous work • Design re-use • Don’t reinvent the wheel • Requires a precise understanding of common, recurring designs • leverage previous work

  36. Some design patterns • Abstract factory • Adapter • Bridge • Command • Composite • Façade • Subject / Observer • Proxy • Strategy

  37. Subject-observer [from Vlissides]

  38. Subject-observer (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer OnUpdate() for all o in observers { o.OnUpdate() }

  39. Subject-observer (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() for all o in observers { o.OnUpdate() } ConcreteSubject ConcreteObserver virtual OnUpdate()

  40. Model / view / controller (MVC) (displays data) View { Model m; Controller c(&m); View v(&c); } (mediates) Controller (holds data) Model calls Register() Main Create() View Create() OnUpdate() Register() Create() Set() Controller Set() Model

  41. MVC (cont.) 1 * Subject Register(Observer) Unregister(Observer) NotifyAll() Observer virtual OnUpdate() for all o in observers { o.OnUpdate() } Controller View virtual OnUpdate()

  42. MVC (cont.) class Observer { protected: virtual void OnUpdate(MsgId message_id) = 0; }; class Subject { public: enum MsgId {}; void RegisterObserver(Observer* obs); virtual void NotifyAllObservers(MsgId message_id) { for (int i=0 ; i<m_observers.size() ; i++) { m_observers[i]->OnUpdate(message_id); } } private: std::vector<Observer*> m_observers; };

  43. MVC (cont.) class Controller : public Subject { Controller(Data* d) : m_data(d) {} const Data* GetData() const; void AddSphere(const Sphere& s) { m_data->AddSphere(s); NotifyAllObservers(ADD_SPHERE); } private: Data* m_data; };

  44. MVC (cont.) class MainWnd : public Observer, CWnd { public: MainWnd(Controller* c) : m_controller(c) { c.Register(this); } virtual void OnUpdate(int message_id) { switch (message_id) { case Subject::ADD_SPHERE: ... } } private: Controller* m_controller; };

  45. Adapter • You have • legacy code • current client • Adapter changes interface of legacy code so client can use it • Adapter fills the gap b/w two interfaces • No changes needed for either • legacy code, or • client

  46. Adapter (cont.) class NewTime { public: int GetTime() { return m_oldtime.get_time() * 1000 + 8; } private: OldTime m_oldtime; };

  47. Command • You have commands that need to be • executed, • undone, or • queued • Command design pattern separates • Receiver from Invoker from Commands • All commands derive from Command and implement do(), undo(), and redo()

  48. Implementing ‘Undo/Redo’ • Multi-level undo/redo requires two classes: • Command • CommandManager class Command { public: virtual bool Execute() = 0; virtual bool Unexecute() = 0; virtual ~Command() { } }; class CommandManager { private: typedef list<Command*> CommandList; CommandList m_undoList; CommandList m_redoList; public: void DoCommand(Command* com); void Undo(); void Redo(); }; http://www.codeproject.com/KB/cpp/undoredo_cpp.aspx

  49. Facade • You • have a set of related classes • want to shield the rest of the system from these details • Facade provides a simplified interface • Encapsulates a subsystem

  50. Composite • You want uniformly to treat • items (atomic elements), and • groups (containing items or other groups) • Composite interface specifies operations that are shared between items and groups • Examples: hierarchy of files and directories, groups of drawable elements

More Related