1. SOFTWARE SYSTEMS DEVELOPMENT 4: System Design

2. Simplified view on software product development process 2 Product Planning System Design Project Planning Project Execution Deployment, support an maintenance

3. Why do we need the design phase?  Make sure requirements are feasible  To plan and estimate the work to be done  Communications (development teams/support/customer etc.)  Prepare for change

4. Software Architecture  “Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled”.  “Architecture is everything that is expensive to change later”  Communications=>Documentation

5. Documenting Architecture: Views  Decomposition of the system into elements  Relationships among elements and attributes of these elements  Run-time vs. Static decomposition?

6. Architecture: Views  Multiple views to capture different aspect of the system:  Functional: elements and connectors  Information: data entities and relationships  Development: layers and modules  Concurrency: processes and threads  Deployment: hardware, network

7. A Functional View: Layered Style

8. An Information: View Entity Relationship Diagram

9. A Development View: Class Diagram

10. Architecture Evaluation  Make sure there is a flow in functional view for each software requirements (SRS)  Make sure there is required set of classes/modules in development view  Make sure all required data is present and maintained correctly

11. Some important points  Detalization -Abstraction trade-off  Development view has enough information for reliable estimation of work to be done  Prepare to change  Run “what-if” analysis on the architecture. See scope and place of changes  Knowledge reuse  Architecture styles(client-server, multitier) and patterns

12. Software Quality  Run-Time Quality  Non-Runtime System Qualities  Business Qualities  Architecture Qualities  Domain Specific Qualities

13. Runtime System Qualities  Functionality Definition: the ability of the system to do the work for which it was intended.  Performance Definition: the response time, utilization, and throughput behavior of the system. Not to be confused with human performance or system delivery time.  Security Definition: a measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.  Availability Definition: the measure of time that the system is up and running correctly; the length of time between failures and the length of time needed to resume operation after a failure.  Usability Definition: the ease of use and of training the end users of the system. Sub qualities: learnability, efficiency, affect, helpfulness, control.  Interoperability Definition: the ability of two or more systems to cooperate at runtime

14. Non-runtime  Modifiability Definition: the ease with which a software system can accommodate changes to its software  Portability Definition: the ability of a system to run under different computing environments. The environment types can be either hardware or software, but is usually a combination of the two.  Reusability Definition: the degree to which existing applications can be reused in new applications.  Integrability Definition: the ability to make the separately developed components of the system work correctly together.  Testability Definition: the ease with which software can be made to demonstrate its faults

15. Business Qualities  Cost and Schedule Definition: the cost of the system with respect to time to market, expected project lifetime, and utilization of legacy and COTS systems.  Marketability Definition: the use of the system with respect to market competition.  Appropriateness for Organization Definition: availability of the human input, allocation of expertise, and alignment of team and software structure. Business process re- engineering

16. Architecture Qualities  Conceptual Integrity Definition: the integrity of the overall structure that is composed from a number of small architectural structures.  Correctness Definition: accountability for satisfying all requirements of the system.

17. Our focus  Run-time: Functionality  Non-runtime: Modifiability  Business: Cost and Schedule  Architecture: Correctness

18. SDD Document: 3 pages/diagrams  Functional (Logical) Architecture diagram  ER Diagram  Class diagram including major classes (top 10 or less) with top 5 methods/attributes per class