![Page 43Classification: Restricted
Swimlanes Registrar Professor
Select courses
to teach
Create
curriculum
Create
catalog
Place catalog
in bookstore
Open
registration
Close
registration
[ Registration time period expired ]
Mail catalog
to students
Activity Diagram for Registration System](https://image.slidesharecdn.com/day6ooadanduml-180811005712/85/OOAD-and-UML-43-320.jpg)
![Page 49Classification: Restricted
public class BlogAccount {
// Attribute introduced thanks to the association with the BlogEntry class
private BlogEntry[] entries;
// ... Other Attributes and Methods declared here ...
}
public class BlogEntry
{
// The blog attribute has been removed as it is not necessary for the
// BlogEntry to know about the BlogAccount that it belongs to.
// ... Other Attributes and Methods declared here ...
}](https://image.slidesharecdn.com/day6ooadanduml-180811005712/85/OOAD-and-UML-49-320.jpg)
![Page 56Classification: Restricted
public class MessageReceiver
{
public void foo( )
{
// Do something inside foo.
}
}
public class MessageCaller
{
private MessageReceiver messageReceiver;
// Other Methods and Attributes of the class are declared here
// The messageRecevier attribute is initialized elsewhere in
// the class.
public doSomething(String[] args)
{
// The MessageCaller invokes the foo( ) method
this.messageReceiver.foo( ); // then waits for the method to return
// before carrying on here with the rest of its work
}
}](https://image.slidesharecdn.com/day6ooadanduml-180811005712/85/OOAD-and-UML-56-320.jpg)
OOAD and UML
- 1. Page 1Classification: Restricted Business Analysis Training Structured vs. Object Orient Analysis and Design SAD vs. OOSAD
- 2. Page 2Classification: Restricted Agenda • SAD Phases • OOAD Phases • SAD vs. OOAD software development • Adopted Books • UML in practice • Conclusions & Recommendations
- 3. Page 3Classification: Restricted Key Differences Between Structured and Object-Oriented Analysis and Design Structured Object-Oriented Methodology SDLC Iterative/Incremental Focus Processs Objects Risk High Low Reuse Low High Maturity Mature and widespread Emerging (1997) Suitable for Well-defined projects with stable user requirements Risky large projects with changing user requirements
- 4. Page 4Classification: Restricted Key Differences Between Structured and Object-Oriented Analysis and Design Phase Structured Object-Oriented Analysis Structuring Requirements • DFDs • Structured English • Decision Table / Tree • ER Analysis Requirement Engineering • Use Case Model (find Uses Cases, Flow of Events, Activity Diagram) • Object Model • Find Classes & class relations • Object Interaction: Sequence & collaboration Diagram, State Machine Diagram, • Object to ER Mapping Design • DB design • (DB normalization) • GUI Design • (forms & reports) • Physical DB design • Design elements • Design system Architecture • Design classes: Checking The Model, Combine Classes, Splitting Classes, Eliminate Classes • Design components • GUI design
- 5. Page 5Classification: Restricted Definitions • Systems Analyst • Responsible for analysis and design of information systems • Software • Computer programs and associated documentation such as requirements, design models and user manuals • Software Engineering • IEEE standard 610-12 (1999) defines software engineering as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
- 6. Page 6Classification: Restricted SW Project phases • Any project in the world has the following phases: • Planning • Analysis: system requirements are studied and structured • Design: recommended solution is converted into logical and then physical system specifications • Logical design – all functional features of the system chosen for development in analysis are described independently of any computer platform • Physical design – the logical specifications of the system from logical design are transformed into the technology-specific details from which all programming and system construction can be accomplished • Implementation • Testing • Maintenance
- 7. Page 7Classification: Restricted Outline • SAD Phases • OOAD Phases • SAD vs. OOAD software development • Adopted Books • UML in practice • Conclusions & Recommendations
- 8. Page 8Classification: Restricted Structured Analysis and Design (SAD) A. Analysis Phase 1. Determine system requirements 2. Structuring system process requirements 3. Logical requirements (logical modeling) 4. Structuring system data requirements B. Design Phase 1. Database design (DB normalization) 2. Forms and report design (GUI design)
- 9. Page 9Classification: Restricted Structured Analysis and Design (SAD) A. Analysis Phase 1. Determine system requirements: • Interviewing: individuals and/or group 2. Structuring system process requirements • Data Flow Diagram (DFD) – logical process modeling • DFD levels (process decomposition) • Context diagram • 4 type of DFD • Current physical: Adequate detail only • Current logical: Enables analysts to understand current system • New logical: Technology independent, Show data flows, structure, and functional requirements of new system • New physical: Technology dependent
- 10. Page 10Classification: Restricted DFD Symbols Comparison of DeMarco and Yourdon and Gane and Sarson DFD symbol sets
- 11. Page 11Classification: Restricted Diagram Depiction of Project Scope Context-level data flow diagram showing project scope for Purchasing Fulfillment System (Pine Valley Furniture)
- 12. Page 12Classification: Restricted Context Diagram Context diagram of Hoosier Burger’s food-ordering system
- 13. Page 13Classification: Restricted Developing DFDs (Cont.) • Level-0 diagram is a data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail. • Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs.
- 14. Page 14Classification: Restricted Level-0 Diagram Level-0 DFD of Hoosier Burger’s food-ordering system
- 15. Page 15Classification: Restricted Data Flow Diagramming Rules
- 16. Page 16Classification: Restricted Data Flow Diagramming Rules (Cont.)
- 17. Page 17Classification: Restricted Decomposition of DFDs • Functional decomposition is an iterative process of breaking a system description down into finer and finer detail. • Creates a set of charts in which one process on a given chart is explained in greater detail on another chart. • Continues until no subprocess can logically be broken down any further.
- 18. Page 18Classification: Restricted Decomposition of DFDs (Cont.) • Primitive DFD is the lowest level of a DFD. • Level-1 diagram results from decomposition of Level-0 diagram. • Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a level-0 diagram.
- 19. Page 19Classification: Restricted Level-1 DFD Level-1 DFD shows the sub-processes of one of the processes in the Level-0 DFD. This is a Level-1 DFD for Process 4.0. Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary. Level-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s food-ordering system
- 20. Page 20Classification: Restricted Level-n DFD Level-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD. This is a Level-2 DFD for Process 4.3. Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest level of the hierarchy, it is called a primitive DFD. Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering system
- 21. Page 21Classification: Restricted Four Different Types of DFDs • Current Physical • Process labels identify technology (people or systems) used to process the data. • Data flows and data stores identify actual name of the physical media. • Current Logical • Physical aspects of system are removed as much as possible. • Current system is reduced to data and processes that transform them.
- 22. Page 22Classification: Restricted Four Different Types of DFDs (Cont.) • New Logical • Includes additional functions. • Obsolete functions are removed. • Inefficient data flows are reorganized. • New Physical • Represents the physical implementation of the new system.
- 23. Page 23Classification: Restricted SAD – Analysis phase (Cont.) 3. Logical requirements (logical modeling) • Use structured English to represent DFD because DFD does not show logic • Use decision table / tree (logical choice in conditional statement 4. Structuring system data requirements • ER diagram
- 24. Page 24Classification: Restricted Modeling Logic with Decision Tables • Decision table: a matrix representation of the logic of a decision which specifies the possible conditions for the decision and the resulting actions. • Best used for complicated decision logic.
- 25. Page 25Classification: Restricted Modeling Logic with Decision Tables (Cont.) Complete decision table for payroll system example
- 26. Page 26Classification: Restricted Modeling Logic with Decision Tables (Cont.) • Condition stubs: that part of a decision table that lists the conditions relevant to the decision • Action stubs: that part of a decision table that lists the actions that result for a given set of conditions
- 27. Page 27Classification: Restricted Modeling Logic with Decision Tables (Cont.) • Rules: that part of a decision table that specifies which actions are to be followed for a given set of conditions • Indifferent condition: in a decision table, a condition whose value does not affect which actions are taken for two or more rules
- 28. Page 28Classification: Restricted Modeling Logic with Decision Tables (Cont.) • Procedure for Creating Decision Tables • Name the condition and the values that each condition can assume. • Name all possible actions that can occur. • List all possible rules. • Define the actions for each rule. • Simplify the table.
- 29. Page 29Classification: Restricted Modeling Logic with Decision Tables (Cont.) Reduced decision table for payroll system example
- 30. Page 30Classification: Restricted SAD – Analysis phase (Cont.) B. Design Phase 1. Database design (DB normalization) 2. Forms and report design (GUI design)
- 31. Page 31Classification: Restricted DB Normalization • Normalization: the process of converting complex data structures into simple, stable data structures • The result of normalization is that every nonprimary key attribute depends upon the whole primary key. • First Normal From (1NF) • Unique rows, no multivalued attributes • All relations are in 1NF • Second Normal Form (2NF) • Each nonprimary key attribute is identified by the whole key (called full functional dependency) • Third Normal Form (3NF) • Nonprimary key attributes do not depend on each other (i.e. no transitive dependencies)
- 32. Page 32Classification: Restricted Object-Oriented Analysis and Design (OOAD) • Based on objects rather than data or processes • Object: a structure encapsulating attributes and behaviors of a real-world entity • Object class: a logical grouping of objects sharing the same attributes and behaviors • Inheritance: hierarchical arrangement of classes enable subclasses to inherit properties of superclasses
- 33. Page 33Classification: Restricted Outline • SAD Phases • OOAD Phases • SAD vs. OOAD software development • UML in practice
- 34. Page 34Classification: Restricted OOSAD A. Analysis Phase • Structuring requirements (Use cases) • Conceptual data modeling (class diagram) • Object relationship modeling • Class diagram → ER diagram • Analysis classes • Class stereotypes • Sequence diagram • Communication diagram • activity diagram • State machine diagram
- 35. Page 35Classification: Restricted OOSAD B. Design Phase • Physical DB design • Design elements • Design classes • Design components • Design system Architecture • GUI design
- 36. Page 36Classification: Restricted Visual modeling with rational rose text book • Focus on Rational Unified Process (RUP) • Talk about 4+1 architectural view Later on the textbook • Rational Rose Example
- 37. Page 37Classification: Restricted OOAD project phases (my reading and experience) • Analysis • Requirement gathering, analysis, and modeling (Requirement Engineering) • Use Case Model find Uses Cases, Flow of Events, Activity Diagram) • Object Model • Find Classes & class relations, • Object Interaction: Sequence & collaboration Diagram, State Machine Diagram, • Object to ER Mapping • Design • Physical DB design • Design elements • Design system Architecture • Design classes: Checking The Model, Combine Classes, Splitting Classes, Eliminate Classes • Design components • GUI design
- 38. Page 38Classification: Restricted Use Cases Examples
- 39. Page 39Classification: Restricted Use Case Diagram in the Course Registration System Student Billing system Register For Courses Maintain Course Information Maintain Professor Information Maintain Student Information Create Course CatalogRegistrar Select Courses to teach Request Course Roster Professor
- 40. Page 40Classification: Restricted Use Case: Clinic System Example
- 41. Page 41Classification: Restricted Use Case: Bank System Example
- 42. Page 42Classification: Restricted Activity Diagram Examples
- 43. Page 43Classification: Restricted Swimlanes Registrar Professor Select courses to teach Create curriculum Create catalog Place catalog in bookstore Open registration Close registration [ Registration time period expired ] Mail catalog to students Activity Diagram for Registration System
- 44. Page 44Classification: Restricted Activity Diagram for Back System
- 45. Page 45Classification: Restricted Activity Diagram for Shipment System
- 46. Page 46Classification: Restricted Finding classes (thinking in objects) (Registration System) Entity class Boundary class (GUI interface) RegistrationManager addStudent(Course, Student) Control class Course name numberCredits open() addStudent(Student) Entity class
- 47. Page 47Classification: Restricted Class relations: Inheritance and Multiplicity (Registration System) 1 0..* 0..* 1 1 1..* 4 3..10 0..4 1 RegistrationForm RegistrationManager Course Student CourseOffering Professor addStudent(Course, Student) name numberCredits open() addStudent(Student) major location open() addStudent(Student} tenureStatus ScheduleAlgorithm name RegistrationUser
- 48. Page 48Classification: Restricted Relationships • Three types of relationships are: • Association • Aggregation • Dependency
- 49. Page 49Classification: Restricted public class BlogAccount { // Attribute introduced thanks to the association with the BlogEntry class private BlogEntry[] entries; // ... Other Attributes and Methods declared here ... } public class BlogEntry { // The blog attribute has been removed as it is not necessary for the // BlogEntry to know about the BlogAccount that it belongs to. // ... Other Attributes and Methods declared here ... }
- 50. Page 50Classification: Restricted Object-Relational Modeling • Purposes of Object-Relational Modeling • Create entity classes • Produce database structures • Enhance and finalize the attributes in the data model
- 51. Page 51Classification: Restricted Object-Oriented Extensions to Relational Modeling • Generalization • Multivalued attributes (OK to violate atomicity requirement of 1NF) • Aggregation • Object identifiers • Pointers • Behaviors • Richer set of data types Object-relational Data Model
- 52. Page 52Classification: Restricted Translating Conceptual Data Model to Object- Relational Model • Translate classes • Translate relationships • Normalize object relations • Merge object relations
- 53. Page 53Classification: Restricted Supertype/subtype relationships
- 54. Page 54Classification: Restricted These are implemented as one-to-one relationships Mapping Supertype/subtype relationships to relations
- 55. Page 55Classification: Restricted Sequence Diagram • A sequence diagram displays object interactions arranged in a time sequence : Student registration form registration manager math 101 1: fill in info 2: submit 3: add student to math 101 4: add student 5: are you open? 6: add student math 101 section 1
- 56. Page 56Classification: Restricted public class MessageReceiver { public void foo( ) { // Do something inside foo. } } public class MessageCaller { private MessageReceiver messageReceiver; // Other Methods and Attributes of the class are declared here // The messageRecevier attribute is initialized elsewhere in // the class. public doSomething(String[] args) { // The MessageCaller invokes the foo( ) method this.messageReceiver.foo( ); // then waits for the method to return // before carrying on here with the rest of its work } }
- 57. Page 57Classification: Restricted : Registrar course form : CourseForm theManager : CurriculumManager aCourse : Course 1: set course info 2: process 3: add course 4: new course Collaboration Diagram • A collaboration diagram displays object interactions organized around objects and their links to one another
- 60. Page 60Classification: Restricted Sequence Diagram for Bank System
- 61. Page 61Classification: Restricted Showing Components Working Together
- 62. Page 62Classification: Restricted Focusing on the key components and interfaces in your system Focusing on component dependencies and the manifesting artifacts is useful when you are trying control the configuration or deployment of your system
- 63. Page 63Classification: Restricted Assembly connectors show components working together through interfaces
- 64. Page 64Classification: Restricted System Architecture
- 65. Page 65Classification: Restricted Key Differences Between Structured and Object-Oriented Analysis and Design Structured Object-Oriented Methodology SDLC Iterative/Incremental Focus Processs Objects Risk High Low Reuse Low High Maturity Mature and widespread Emerging Suitable for Well-defined projects with stable user requirements Risky large projects with changing user requirements
- 66. Page 66Classification: Restricted Software Engineering The systems engineering process Requirement definitions System design Subsystem development System integration System installation System evaluation System decomposition