Approaching the Design Stages

1. Approaching the Design Stages PongtipAroonvatanaporn CSCI577 Fall 2011 November 7, 2011 USC-CSSE

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

3. Valuation vs. Foundation • From design/architecture perspective • What are the main differences? • Why have Valuation Phase? • Why have Foundations Phase? USC-CSSE

4. 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

5. 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

6. 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

7. 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

8. Outline • Looking back • Moving into Design • Core Components of Design • Exercise USC-CSSE

9. System Analysis • System analysis focus on: • System context • System users and actors • Persistent data (Artifacts and Information) • Often reflects database schema • Data that are “permanently”stored • Update to reflect any requirement changes • Better understanding of project, concepts, and goals USC-CSSE

10. Design • Design focus on: • System execution architecture • In-memory data • Data that are retrieved from database during execution • Data obtained from system during execution • Complete logic of system’s operations • Implement all the critical use-cases USC-CSSE

11. Outline • Looking back • Moving into Design • Core Components of Design • Exercise USC-CSSE

12. 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

13. 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

14. Hardware Components USC-CSSE

15. Software Components USC-CSSE

16. Deployment USC-CSSE

17. 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

18. 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

19. 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

20. 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

21. 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

22. Clock In Sequence USC-CSSE

23. 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

24. Outline • Looking back • Moving into Design • Core Components of Design • Exercise USC-CSSE

25. 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 USC-CSSE

26. 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 USC-CSSE

27. Information to store • Volunteer information • Employee information • Awards • Time sheet • Jobs USC-CSSE

28. 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

29. Artifacts and Information Diagram USC-CSSE

30. Time Management Class USC-CSSE