Skip to main content
Structured vs. Object Orient Analysis and DesignSAD vs. OOSADMotaz K. Saad May 2010
Outline SAD PhasesOOAD PhasesSAD vs. OOAD software development Adopted BooksUML in practice Conclusions & Recommendations 2
TextbooksModern Systems Analysisand Design6th EditionJeffrey Hoffer Joey GeorgeJoseph Valacich3Object Oriented Systems  Analysis and Design 2nd   edition Joey GeorgeDinesh BatraJoseph ValacichJeffrey HofferSoftware Engineering8th , 9th edition Lan SummervilleLearning UML 2.0, By Kim Hamilton, Russell Miles, O'Reilly, 2006.Visual Modeling with Rational Rose 2002 and UML, 3/E, by Terry Quatrani
Papers 4In practice - UML software architecture and design description, IEEE Software, 2006The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.
Key Differences Between Structured and Object-Oriented Analysis and Design5
Key Differences Between Structured and Object-Oriented Analysis and Design6
Definitions Systems AnalystResponsible for analysis and design of information systemsSoftware Computer programs and associated documentation such as requirements, design models and user manualsSoftware EngineeringIEEE 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.7
SW Project phases	Any project in the world has the following phases:PlanningAnalysis: system requirements are studied and structuredDesign: recommended solution is converted into logical and then physical system specificationsLogical 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 accomplishedImplementationTesting Maintenance 8
Outline SAD PhasesOOAD PhasesSAD vs. OOAD software development Adopted BooksUML in practice Conclusions & Recommendations 9
Structured Analysis and design (SAD)A. Analysis PhaseDetermine system requirementsStructuring system process requirementsLogical requirements (logical modeling)Structuring system data requirementsB. Design PhaseDatabase design (DB normalization)Forms and report design (GUI design)10
Structured Analysis and design (SAD)A. Analysis PhaseDetermine system requirements:Interviewing: individuals and/or groupStructuring system process requirementsData Flow Diagram (DFD) – logical process modelingDFD levels (process decomposition)Context diagram 4 type of DFDCurrent physical: Adequate detail onlyCurrent logical: Enables analysts to understand current systemNew logical: Technology independent, Show data flows, structure, and functional requirements of new systemNew physical: Technology dependent 11
DFD SymbolsComparison of DeMarco and Yourdonand Gane and Sarson DFD symbol sets12
Diagram Depiction of Project ScopeContext-level data flow diagram showing project scope for Purchasing Fulfillment System (Pine Valley Furniture)13
Context DiagramContext diagram of Hoosier Burger’s food-ordering system14
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.15
Level-0 Diagram16Level-0 DFD of Hoosier Burger’s food-ordering system
Data Flow Diagramming Rules17
Data Flow Diagramming Rules (Cont.)18
Decomposition of DFDsFunctional 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.19
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.20
Level-1 DFDLevel-1 diagram showing the decomposition of Process 4.0 from the level-0 diagram for Hoosier Burger’s food-ordering systemLevel-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.21
22Level-n DFDLevel-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering systemLevel-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.
Four Different Types of DFDsCurrent PhysicalProcess labels identify technology (people or systems) used to process the data.Data flows and data stores identify actual name of the physical media. Current LogicalPhysical aspects of system are removed as much as possible.Current system is reduced to data and processes that transform them.23
Four Different Types of DFDs (Cont.)New LogicalIncludes additional functions.Obsolete functions are removed.Inefficient data flows are reorganized.New PhysicalRepresents the physical implementation of the new system.24
SAD – Analysis phase (Cont.)Logical requirements (logical modeling)Use structured English to represent DFD because DFD does not show logicUse decision table / tree (logical choice in conditional statement Structuring system data requirementsER diagram25
Modeling Logic with Decision TablesDecision 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.26
Modeling Logic with Decision Tables (Cont.)Complete decision table for payroll system example27
Modeling Logic with Decision Tables (Cont.)Condition stubs: that part of a decision table that lists the conditions relevant to the decisionAction stubs: that part of a decision table that lists the actions that result for a given set of conditions28
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 conditionsIndifferent condition: in a decision table, a condition whose value does not affect which actions are taken for two or more rules29
Modeling Logic with Decision Tables (Cont.)Procedure for Creating Decision TablesName 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.30
31Modeling Logic with Decision Tables (Cont.)Reduced decision table for payroll system example
SAD – Analysis phase (Cont.)B. Design PhaseDatabase design (DB normalization)Forms and report design (GUI design)32
DB NormalizationNormalization: the process of converting complex data structures into simple, stable data structuresThe result of normalization is that every nonprimary key attribute depends upon the whole primary key.First Normal From (1NF)Unique rows, no multivalued attributesAll relations are in 1NFSecond 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)33
Object Oriented Analysis and DesignOOAD34
Object-Oriented Analysis and Design (OOAD)Based on objects rather than data or processesObject: a structure encapsulating attributes and behaviors of a real-world entity35
Object-Oriented Analysis and Design (OOAD) (Cont.)Object class: a logical grouping of objects sharing the same attributes and behaviorsInheritance: hierarchical arrangement of classes enable subclasses to inherit properties of superclasses36
Outline SAD PhasesOOAD PhasesSAD vs. OOAD software development Adopted BooksUML in practice Conclusions & Recommendations 37
OOSAD textbookA. Analysis PhaseStructuring requirements (Use cases)Conceptual data modeling (class diagram)Object relationship modelingClass diagram -> ER diagram Analysis classesClass stereotypesSequence diagramCommunication diagram  activity diagramState machine diagram38
OOSAD textbookB. Design PhasePhysical DB designDesign elements Design classesDesign components Design system ArchitectureGUI design39
Learning UML textbookFocus on 4+1 view architecture 40Modeling a System's Logical Structure: Introducing Classes and Class, Sequence State Machine DiagramsModeling Requirements: Use CasesModeling System Workflows: Activity DiagramsManaging and Reusing Your System's Parts: Component, Package, Deployment, Diagrams
Visual modeling with rational rose text bookFocus on Rational Unified Process (RUP)Talk about 4+1 architectural view Later on the textbookRational Rose Example41
OOAD project phases(my reading and experience)AnalysisRequirement 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 MappingDesignPhysical DB designDesign elements Design system ArchitectureDesign classes: Checking The Model, Combine Classes, Splitting Classes, Eliminate ClassesDesign components GUI design42
Use Cases Examples43
Use Case Diagram in the ESU Course Registration System44
Use Case: Clinic System Example45
Use Case: Bank System Example46
Activity diagram Examples47
Create curriculumSelect courses to teachCreate Activity Diagram for registration systemRegistrarProfessorcatalogMail catalog Place catalog to studentsin bookstoreOpen registration[ Registration time period expired ]SwimlanesClose registration48
49Activity Diagram for back system
Activity Diagram for shipment system50
Finding classes (thinking in objects)(Registration System)51Boundary class (GUI interface)Entity classControl classRegistrationManagerEntity classCourseaddStudent(Course, Student)namenumberCreditsopen()addStudent(Student)
Class relations: Inheritance and Multiplicity(Registration System)0..*110..*13..1041..*10..4ScheduleAlgorithmRegistrationFormRegistrationManageraddStudent(Course, Student)CoursenameRegistrationUsernumberCreditsnameStudentopen()addStudent(Student)majorProfessorCourseOfferingtenureStatuslocationopen()addStudent(Student}
RelationshipsThree types of relationships are:AssociationAggregationDependency53
54public class BlogAccount {   // Attribute introduced thanks to the association with the BlogEntry classprivate 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 ...}
Object-Relational ModelingPurposes of Object-Relational ModelingCreate entity classesProduce database structuresEnhance and finalize the attributes in the data model55
Object-Oriented Extensions to Relational ModelingGeneralizationMultivalued attributes (OK to violate atomicity requirement of 1NF)AggregationObject identifiersPointersBehaviorsRicher set of data typesObject-relational Data Model56
Translating Conceptual Data Model to Object-Relational ModelTranslate classesTranslate relationshipsNormalize object relationsMerge object relations57
Supertype/subtype relationships58
Mapping Supertype/subtype relationships to relationsThese are implemented as one-to-one relationships59
Sequence Diagramregistration registration math 101 : Studentformmanagermath 101 section 11: fill in info2: submit3: add student to math 1014: add student5: are you open?6: add studentA sequence diagram displays object interactions arranged in a time sequence60
61public class MessageReceiver{public void foo(  )   {      // Do something inside foo.   }}public class MessageCaller{   private MessageReceivermessageReceiver;   // 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(  ) methodthis.messageReceiver.foo(  ); // then waits for the method to return      // before carrying on here with the rest of its work   }}
Collaboration Diagramcourse form : 1: set course infoCourseForm2: process3: add course : RegistrartheManager : aCourse : CurriculumManagerCourse4: new courseA collaboration diagram displays object interactions organized around objects and their links to one another62
63
64
Sequence Diagram for Bank System65
State Machine Diagram66
67State Machine Diagram
68Showing Components Working Together
69Focusing on the key components and interfaces in your systemFocusing on component dependencies and the manifesting artifacts is useful when you are trying control the configuration or deployment of your system
70Assembly connectors show components working together through interfaces
System Architecture 71
Key Differences Between Structured and Object-Oriented Analysis and Design72
Software Engineering textbookMain topics INTRODUCTIONSocio-technical SystemEmergent propertyREQUIREMENTS ENGINEERINGSystems ModelsDESIGNArchitectural DesignApplication ArchitecturesObject-oriented DesignReal-time SystemsUser Interface DesignSOFTWARE DEVELOPMENTIterative SW DevelopmentSW ReuseCBSECritical Systems DevelopmentSoftware EvolutionVALIDATIONVerification and ValidationSoftware TestingCritical Systems ValidationMANAGEMENTSoftware Cost EstimationQuality Management
Software Engineering textbookMain topics (Cont.)EMERGING TECHNOLOGIESSecurity EngineeringService-oriented Software EngineeringAspect-oriented Software Development
Software Engineering textbookSystem categoriesTechnical computer-based systemsSystems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware.Socio-technical systemsSystems that include technical systems but also operational processes and peoplewho use and interact with the technical system. Socio-technical systems are governed by organisational policies and rules.
Software Engineering textbookSocio-technical system characteristicsEmergent propertiesProperties of the system of a whole that depend on the system components and their relationships.Non-deterministicThey do not always produce the same output when presented with the same input because the systems’s behaviour is partially dependent on human operators.Complex relationships with organisational objectivesThe extent to which the system supports organisational objectives does not just depend on the system itself.
Software Engineering textbookTypes of emergent propertyFunctional properties These appear when all the parts of a system work togetherto achieve some objective. For example, a bicycle has the functional property of being a transportationdevice once it has been assembled from its components.Non-functional emergent propertiesExamples are reliability, performance, safety, and security. These relate to the behaviour of the system in its operational environment.They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.
Software Engineering textbookThe systems engineering process
Software Engineering textbookInter-disciplinary involvement
Software Engineering textbookSystem ModelsContext models Blocks (box diagram of subsystems)DFDs can be usedBehavioural modelsBlocks (box diagram of subsystems)Two types of behavioral model are:Data processing models that show how data is processed as it moves through the system (DFD)State machine models that show the systems response to events.Data models DFDsObject modelsInheritance modelsAggregation modelsInteraction models80
Key Differences Between Structured and Object-Oriented Analysis and Design81
Papers 82In practice - UML software architecture and design description, IEEE Software, 2006The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.A Realistic Empirical Evaluation of the Costs and Benefits of UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.
Papers 83In practice - UML software architecture and design description, IEEE Software, 2006
Practitioner reflections on UML use2+ month period, 80 architects participated. major responsibilities among respondents:analysis (66 %),design (66 %),specification (61 %), andprogramming (52 %).The respondents came from different application domains.Most worked in information systems (61 %)28 % worked in embedded systemsa few worked in tool and operating systems development. 60% worked in projects of more than 5 person-years.84
Survey respondents’ use of UML for 4+1 architectural views85
Survey respondents’ assessment of their adherence to the UML standard.86
Deadline vs. completeness as stopping criteria for different project sizes.87
Problems encountered due to incomplete models correlated to respondent demographic data regarding project size.88
Problems with UML descriptionsScattered information:Design choices are scattered over multiple views.some dependencies might show up in the logical view, while others appear in the process view.Incompleteness:The architects focus on what they think is important.Inconsistency. UML-based software development is inevitably inconsistent. Industrial systems are typically developed by teams.Different teams can have different understandings of the system as well as different modeling styles, and this can lead to inconsistent models.89
Other problem classes include the following:Diagram quality. UML lets architects represent one design in different ways. they can decompose a diagram that contains too many elements into several smaller diagrams. they can influence how easy the model is to understand and how it gets interpreted.Informal use. Architects sometimes use UML in a very sketchy manner. These diagrams deviatefrom official UML syntax, making their meaning ambiguous.Lack of modeling conventions. case studies show that engineers use UML according to individual habits. These habits might include layout conventions, commenting, visibility of methods and operations, and consistency between diagrams.90
Defects in industrial UML modelsSubjectiveimpression obtained via the surveyObjectivemeasurements about the quality of industrial UML models. (14 case studies of different sizes from various organizations and application domains)91
Defects found in the case studiesMethods that are not called in sequence diagramsClasses not occurring in sequence diagramsObjects without namesMessages not corresponding to methodsClasses without methods92
Papers 93The Impact of UML Documentation on Software Maintenance - An Experimental Evaluation, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 32, NO. 6, JUNE 2006.
It is important to investigate the benefits obtained from modeling. this paper reports on controlled experiments, spanning two locations, that investigate the impact of UML documentation on software maintenance. Results show that: for complex tasks and past a certain learning curve, the availability of UML documentation may result in significant improvements in the functional correctness of changes as well as the quality of their design.there does not seem to be any saving of time. For simpler tasks, the time needed to update the UML documentation may be substantialcompared with the potential benefits, thus motivating the need for UML tools with better support for software maintenance94
95
96
Experimental resultsThe goal was to shed some light on the cost effectiveness of model-driven development with UML. focused on whether models help software engineers to make quicker and better changes to existing systems. The results of the two experiments are mostly consistent. When considering only the time required to make code changes, using UML documentation does help to save effort overall. On the other hand, when including the time necessary to modify the diagrams,  no savings in effort are visible. in terms of the functional correctness of the changes:using UML has a significant, positive impact on the most complex tasks.In the Ottawa experiment, which also investigated the design of the changes, using UML helped to achieve changes with superior design quality, which would then be expected to facilitate future, subsequent changes.the above statements apply only with qualifications.Benefits are not likely to be derived if the tasks to be performed lie belowa certain level of complexityor if software engineers have not reached a certain level of skill regarding the use of UML models for analyzing the effects of changes, in addition to having received substantial training in UML modeling. Furthermore, current tools still need substantial improvements in the way they support changes to models and the checking of consistency.97
Papers 98A Realistic Empirical Evaluation of the Costsand Benefitsof UML in Software Maintenance, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 3, MAY/JUNE 2008.
The Unified Modeling Language (UML) is the de facto standard for object-oriented software analysis and design modeling.few empirical studies exist which investigate the costsand evaluate the benefitsof using UML in realistic contexts. Such studies are needed so that the software industry can make informed decisions regarding the extent to which they should adopt UML in their development practices. 99
This is the first controlled experiment that investigates the costs of  maintaining and the benefits of using UML documentation during the maintenance and evolution of a real nontrivial system, using professionaldevelopersas subjects, working with a state-of-the-art UML tool during an extended period of time. Control Group: had no UML documentationUML Group: had UML documentation.had, on average, a practically and statistically significant 54% increase in the functional correctness of changes  (p = 0.03)insignificant 7% overall improvement in design quality (p = 0.22)100