Software AnalysisWhat Is Analysis, and Why?Comparison Between Use Case and Analysis ModelsWorkers and ArtifactsOverview of Relevant UML NotationsGeneralizationMultiplicityAggregationInheritanceStructural RelationshipsClass DiagramModeling Collaboration RelationshipModeling SchemaAdvanced ClassesStructure and Composition of Analysis ModelAnalysis ClassKey Attributes and Subtypes of Analysis ClassBoundary ClassExampleEntity ClassSlide 21Control ClassSlide 23Software AnalysisWhat Is Analysis, and Why?•Transform use case model into logical design, without(*) considering implementation conditions, constraints and details.•Product: The analysis model•Why do we need analysis?–Handle complexity via separation of concerns–A platform, implementation independent design that precisely reflect the requirements, that can be reused, that can sustain technological and environment changes, and that serves as the basis for stable and extensible system structureComparison Between Use Case and Analysis ModelsWorkers and ArtifactsOverview of Relevant UML Notations•Structural views and relationshipsGeneralizationMultiplicityAggregationInheritanceStructural RelationshipsClass DiagramModeling Collaboration RelationshipModeling SchemaAdvanced ClassesStructure and Composition of Analysis ModelAnalysis Class•An analysis class represents an abstract of one or more classes and/or subsystems in (subsequent) design•Characteristics–focuses on handling functional requirements (?**)–seldom defines and provides any interface in terms of operations and their signatures (?**)–defines attributes (high level, and recognizable from problem domain–is involved in relationships at conceptual level–always fit one of 3 basic stereotypes: boundary, control and entity  to achieve model robustnessKey Attributes and Subtypes of Analysis ClassBoundary Class•Models interaction between actor and system•Models parts of system that depend on its actors - they clarify and collect requirements on the system’s boundary•Often represents abstractions of windows, forms, panes, communication interfaces, printer interfaces, sensors, terminals, and possibly APIs •Each boundary class should be related to at least one actor and vice versaExampleEntity Class•Used to model long lived information, and thus often persistent•Models information and associated behavior of some phenomenon or concept, e.g. individual, real-life object, or real-life event•In most cases, entity class are derived from corresponding business class (domain class), but reflect the information that benefits the developers•Used to isolate changes that they representExampleControl Class•Represent coordination, sequencing, transactions and control of other objects•Often used to encapsulate control related to a specific use case•Also represent complex derivations and calculations, e.g. business logic, that cannot be related to any specific, long-lived information•Therefore, control classes model the dynamics of the system•Used to encapsulate, thus isolate, change to control, coordination, sequencing, transactions and complex business