1 / 28

Approaching the Design Stages

Approaching the Design Stages. Pongtip Aroonvatanaporn CSCI577 Fall 2010 November 10, 2010. Outline. Looking back Moving into Design Exercise. Design in Valuation. Less structured Focus on analyzing system to be built “Translate” concepts and requirements into design language

lerato
Download Presentation

Approaching the Design Stages

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. Approaching the Design Stages Pongtip Aroonvatanaporn CSCI577 Fall 2010 November 10, 2010 USC-CSSE

  2. Outline • Looking back • Moving into Design • Exercise USC-CSSE

  3. Design in Valuation • Less structured • Focus on analyzing system to be built • “Translate” concepts and requirements into design language • May have mismatches and unresolved issues • But high risks items must be addressed • Develop at least 1 feasible architecture • TIM or TSM USC-CSSE

  4. For 577 • System analysis • System context • Information architecture • Use-cases • Only focused on the behavior of the system • What can the system do? • No specific details yet • No actual implementation USC-CSSE

  5. Forward to Foundations • Translate system behavior into detailed designs and implementations • Convince stakeholders that you have a stable architecture • Based on risks and values • Commit to 1 architecture for development • Something that is feasible • No unresolved issues or items • No “potential” elements • No unreferenced items (traceability) USC-CSSE

  6. For 577 • Polish up the system analysis model • Develop a Technology-Specific Design • High risk items • Architecturally significant items • Specify all technologies used • Complete traceability of critical use-cases USC-CSSE

  7. Outline • Looking back • Moving into Design • Exercise USC-CSSE

  8. Moving to Design • System analysis focus on: • System context • System users and actors • Persistent data (Artifacts and Information) • Often reflects database schema • Data that are “permanently” stored • Design focus on: • System execution architecture • In-memory data • Data that are retrieved from database during execution • Data obtained from system during execution USC-CSSE

  9. Software Deployment • An important perspective • Helps determine feasibility of implementation • Hardware and platform support • All software must be deployed • Most 577 projects have trivial deployment configurations • Few hardware nodes • Rare concerns with mobile USC-CSSE

  10. Deployment Model • Hardware Components • Include the technologies/platform that run on the hardware • Software Components • Contain the executing classes • Deployment • Placement of executable components on physical hosts • “Instances” of components USC-CSSE

  11. Hardware Components USC-CSSE

  12. Software Components USC-CSSE

  13. Deployment USC-CSSE

  14. Design Classes • Boundary classes • The “end” of the system • What the user sees or interacts with • Control classes • Contains the logic of the system • Entity classes • The entity or data used during execution time • “In-memory” data USC-CSSE

  15. Association Relationships • Association • Ability for one component to communicate with another component class A { private: B* itsB; }; *http://ootips.org/uml-hasa.html USC-CSSE

  16. Composition Relationship • Composition • Components live and die with the parent class Car { public: virtual ~Car() {delete itsCarb;} private: Carburetor* itsCarb }; *http://ootips.org/uml-hasa.html USC-CSSE

  17. Aggregation Relationship • Aggregation • Whole/part relationship • The same as association, but no cyclic relationship • Part cannot contain its whole class Node { private: vector<Node*> itsNodes; }; *http://ootips.org/uml-hasa.html USC-CSSE

  18. Sequence Diagram • Logical sequence representation of the design classes • Only model for major use-cases • Include all involved classes • Controller • Entities • Boundaries • Actors • Etc. USC-CSSE

  19. Clock In Sequence USC-CSSE

  20. Notes • Always treat NCS components as external component or actors • Treat NDI as a component (you do not know its underlying architecture) • Only design what you can implement USC-CSSE

  21. Outline • Looking back • Moving into Design • Exercise USC-CSSE

  22. Volunteer Tracking System • A system to manage volunteers • Online volunteer application submission • Time tracking system • Job management • Authentication • Volunteer management • Award notifications • Interfaces with two other systems • EventRSVP (authentication interface) • Newsletter Systems (email interface) • Provide Person Management mechanisms • Simplified for this session

  23. Technologies Utilized • Symfony • PHP framework • Implements Model-View-Controller (MVC) • Provides abstractions between the 3 layers • PHP • MySQL • Apache • FreeBSD • Supports Internet Explorer and Firefox

  24. Information to store • Volunteer information • Employee information • Awards • Time sheet • Jobs

  25. HW/SW Components • Hardware • FreeBSD application server • Windows workstations • Mac OS X workstations • Software components • User Interface components • Time management component • User management component • Job management component USC-CSSE

  26. Ends at 1:10 pm • DEN students: Take 20 mins to evaluate and answer

  27. Artifacts and Information Diagram

  28. Time Management Class USC-CSSE

More Related