Software Analysis and Design - The Good, bad and Ugly

Transcript

1. Software Analysis & Design The Good, The Bad, The Ugly
2. Abid Jamil Engineering Manager @ JUGNU 9 Years of Experience in Building and Scaling Mobile Products. Tech Writer, Open Source Contributor & CS Researcher. Contributed in digitalisation of KPK Police. Active tech speaker and has delivered many talks at national and international venues. About Me Development Techniques UML Summary
3. Data Driven Development Data-driven software development is based on solid metrics like Key Performance Indicators (KPIs) or Objectives And Key Results (OKRs). About Me Development Techniques UML Summary
4. Behavior Driven Development BDD is a way for the software team to work that closes the gap between business people and technical people About Me Development Techniques UML Summary
5. Functional Vs Non Functional Functional requirements define what a product must do, what its features and functions are. Nonfunctional requirements describe the general properties of a system About Me Development Techniques UML Summary
6. Writing Software Requirements When faced with the prospect of writing requirements, many organizations improvise their own methods. Functional Requirements Writing Techniques • Writing User Stories. • Defining Conditions of Satisfaction. • Creating workflow diagrams. • The use of wireframes and visual designs. • Creating test tables and test scenarios. Tools & Techniques 
 User Stories. Conditional Requirements Workflows Wireframes Test Scenarios About Me Development Techniques UML Summary
7. Writing User Stories A user story is an informal, general explanation of a software feature written from the perspective of the end user. As a <type of user>, I want <some goal> so that <some reason>. About Me Development Techniques UML Summary
8. Maintain Balance Keep balance between non functional and functional requirements. About Me Development Techniques UML Summary
9. Quality Attributes as Non Functional Requiredment Keep balance between non functional and functional requirements. The system Should be easy to use by medical staff and should be organized in such a way that user errors are minimized About Me Development Techniques UML Summary
10. Quality Attributes as Non Functional Requiredment Keep balance between non functional and functional requirements. Medical staff should be able to use all the system functions after 4 hours of training. After this training, the average numbers of errors made by experienced user shall not exceed two per hour of system use. About Me Development Techniques UML Summary
11. Functional , Non Functional Trade Off Good, Fast, Cheap Pick Two About Me Development Techniques UML Summary
12. Use Case Modeling A use case is a methodology used in system analysis to identify, clarify and organize system requirements. Use case 
 Use cases are stories. A simple and familiar model that many people, especially nontechnical, can easily relate to. About Me Development Techniques UML Summary
13. Use Case Modeling A use case is a methodology used in system analysis to identify, clarify and organize system requirements. <Include> <Extend> 
 Extend relationship: The use case is optional and comes after the base use case. · 
 Include relationship: The use case is mandatory and part of the base use case. About Me Development Techniques UML Summary
14. About Me Development Techniques UML Summary
15. About Me Development Techniques UML Summary
16. Brief Use case Brief Use Cases also called High Level Use cases About Me Development Techniques UML Summary
17. About Me Development Techniques UML Summary
18. About Me Development Techniques UML Summary
19. High Level and Extended Use Cases Very Common But Ugly About Me Development Techniques UML Summary
20. Rules for Extended Use Cases Extensive User System Dialog About Me Development Techniques UML Summary
21. 1. ID: a unique identifier to represent the Use Case. 2. Name: what it says on the tin; should be a clear and short name. 3. Description: a brief description (not War and Peace!) of the Use Case. 4. Primary Roles / Actors: the type of primary users that the Use Case relates to. 5. Pre-conditions: what conditions/assumptions need to be in place for the Use Case to start. 6. Trigger: what event will trigger the start of the Use Case. 7. Basic Flow: illustrates the set of steps the role will take to accomplish the objective of the Use Case, as well as the responses from the system. The Basic Flow represents the ‘perfect scenario’, where there are no errors or exceptions in the user’s experience. 8. Alternate Flows: illustrates the ‘unbeaten path’, that is, the less common user and system interactions, as well as exceptions preventing the user from achieving their goal. 9. Post-conditions: what conditions/assumptions need to be in place when the Use Case is complete. Extended/Expanded Use case About Me Development Techniques UML Summary
22. About Me Development Techniques UML Summary
23. Operations Contract Use Cases often fully describe the behavior of a System But they may not be enough. Operation Contracts describe how the internal state of the concepts in the Domain Model may change Operation Contracts are described in terms of preconditions and postconditions About Me Development Techniques UML Summary
24. About Me Development Techniques UML Summary
25. Writing Operations Contract Operation—name of operation (parameters) Cross Reference—the Use Cases in which the OC occurs Preconditions—noteworthy assumptions about state of system or objects in DM before execution Postconditions—state of objects in DM after execution of operation About Me Development Techniques UML Summary
26. Writing Operations Contract Operation—name of operation (parameters) Cross Reference—the Use Cases in which the OC occurs Preconditions—noteworthy assumptions about state of system or objects in DM before execution Postconditions—state of objects in DM after execution of operation About Me Development Techniques UML Summary
27. Post conditions Operations Contract Instance creation or deletion Association formed or broken Attribute modification About Me Development Techniques UML Summary
28. Post conditions Operations Contract Identify system operations from the SSDs Identify complex system operations Construct a contract for each of the above; for postconditions, use the following categories Instance created-deleted Attribute modified Association formed-brokenI About Me Development Techniques UML Summary
29. System Sequence Diagram About Me Development Techniques UML Summary
30. Good Usecase flow can be translated into SSD About Me Development Techniques UML Summary
31. Good Use case flow can be translated into SSD About Me Development Techniques UML Summary
32. Sequence Diagram About Me Development Techniques UML Summary
33. Sequence Diagram About Me Development Techniques UML Summary Object Dimension • The horizontal axis shows the elements that are involved in the interaction • Conventionally, the objects involved in the operation are listed from left to right according to when they take part in the message sequence. However, the elements on the horizontal axis may appear in any order Time Dimension 
 
 The vertical axis represents time proceedings (or progressing) down the page. Note that: Time in a sequence diagram is all a about ordering, not duration. The vertical space in an interaction diagram is
34. Sequence Diagram About Me Development Techniques UML Summary Object Dimension • The horizontal axis shows the elements that are involved in the interaction • Conventionally, the objects involved in the operation are listed from left to right according to when they take part in the message sequence. However, the elements on the horizontal axis may appear in any order Time Dimension 
 
 The vertical axis represents time proceedings (or progressing) down the page. Note that: Time in a sequence diagram is all a about ordering, not duration. The vertical space in an interaction diagram is
35. Domain Modeling Conceptual Modelling (sometimes called Domain Modelling) is the activity of finding out which concepts are important to our system. This process helps us to understand the problem further, and develop a better awareness of our customer’s business About Me Development Techniques UML Summary
36. Domain Modeling If the customer doesn’t understand the concept, it probably isn’t a concept! About Me Development Techniques UML Summary
37. Domain Modeling A domain model gives a conceptual visualization of the problem, it shows: domain objects or conceptual classes associations between conceptual classes attributes of conceptual classes A domain model does not represent software classes : no artificial, programming-related (e.g. interface classes), About Me Development Techniques UML Summary
38. CRC (Class, Responsibility, Collaborator) model About Me Development Techniques UML Summary
39. Only capture high level abstract information About Me Development Techniques UML Summary
40. Only capture high level abstract information About Me Development Techniques UML Summary
41. Noun, Verb Analysis About Me Development Techniques UML Summary
42. Noun, Verb Analysis About Me Development Techniques UML Summary
43. Class Diagram Class diagrams are one of the most useful types of diagrams in UML as they clearly map out the structure of a particular system by modeling its classes, attributes, operations, and relationships between objects. About Me Development Techniques UML Summary
44. Class Diagram We don’t make classes to convert them in code. We can use them at three different levels. Real world projects may have thousands of classes. How can we display all of them in class diagram? About Me Development Techniques UML Summary
45. The answer is: You DON’T NEED TO.. About Me Development Techniques UML Summary
46. • Conceptual view (Domain model) • • Specification view (Business logic and underlying responsibility/ distribution among components/modules) • Implementation View (MDA, model to code....doomed, not used in industry) 3 Views of Class Diagram About Me Development Techniques UML Summary
47. Why I am against MDA? Model Driven Architecture About Me Development Techniques UML Summary
48. Because Grady Booch, the inventor of UML himself is against that. He gave a clear opinion about the actual purpose of UML.. N that’s loud n clear… About Me Development Techniques UML Summary
49. About Me Development Techniques UML Summary
50. Activity Diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. About Me Development Techniques UML Summary
51. Activity Diagram About Me Development Techniques UML Summary
52. Activity Diagram Only use Fork n join for parallel activities. Use Swim lanes if multiple departments or roles. Don’t connect two decision nodes About Me Development Techniques UML Summary
53. Use of Merge Node About Me Development Techniques UML Summary
54. Use of Fork About Me Development Techniques UML Summary
55. Architecture Diagram Use Block Diagram to present the architecture, 
 
 Avoid use of Data Flow Diagram to present Architecture About Me Development Techniques UML Summary
56. Architecture Diagram About Me Development Techniques UML Summary
57. Summary About Me Development Techniques UML Summary Internal operations captured in Use case diagrams. Do: (Only capture features to be exposed to users and focus on user goals only). CRUD operations add, read, update, delete etc should not be captured too. Focus on high level objective like manage user profiles Operational contracts format violation, Specifically post condition is neglected. Do: (Identify system operations from the SSDs, Then shortlist subtle or complex system operations, then make contract for them. Don’t forget DM’s relation with Ocs. Post condition must contain Instance created- deleted, Attribute modified, Association formedbroken
58. Summary About Me Development Techniques UML Summary Construction of SSD for every use case. Do: SSD for brief use case is not required. Operation signatures are not complete in class diagram. Class Diagram & Sequence diagram are not synchronized. Do: Classes in Class diagram, must be instantiated in sequence diagram. Provide complete detail of return types, parameters etc in OS
59. THANK YOU