Analysis and Design Models

Analysis and Design

• Analysis determines business needs and how to build the system
• Design evolves analysis representations into design representations
• Design includes user interface, system input/output design
• Physical architecture decisions involve hardware/software and system processing

Verifying and Validating Analysis Models

• Analysis models must be verified and validated before evolving into design representations
• Verification and validation ensures models faithfully represent the problem domain

Evolving Analysis Models into Design Models

• Design models increase likelihood of successful system delivery, implementing functional requirements in an affordable and maintainable manner
• System design addresses functional and nonfunctional requirements
• Analysis models are reviewed through a design lens
• Modifications enhance efficiency and effectiveness of the evolving system
• Factoring, partitions, collaborations, and layers help evolve problem domain-oriented analysis models into optimal solution domain-oriented design models

Factoring

• Factoring separates a module into a stand-alone module
• The new module can be a new class or method
• Abstraction creates higher-level ideas
• Identifying the Employee class is an example of abstracting from a set of lower classes to a higher one
• Refinement is the opposite of abstraction

Partitions & Collaborations

• A partition is the object-oriented equivalent of a subsystem
• Subsystems decompose a larger system into component systems
• An accounting information system is divided into accounts-payable, accounts-receivable, and payroll systems
• Packages and package diagrams model partitions and collaborations
• Collaborations should be merged when classes support multiple use cases
• Cluster analysis or multiple dimensional scaling identifies classes for collaboration, based on affinity
• Affinity is based on semantic relationships, message types (create, read, update, delete, execute), or a combination
• Objects sending more messages are more likely to belong in the same partition
• Modeling collaborations involves clients, servers, and contracts
• Clients send messages, servers receive messages, and contracts formalize interactions
• Identifying collaborations and partitions helps determine which classes to group in design

Layers

• Software architecture should have layers for different system environment elements
• Data management, UI, physical architecture
• Layers can be portrayed using packages and package diagrams

Packages and Package Diagrams

• In UML, packages represent collaborations, partitions, and layers
• Packages are similar to computer folders
• Package diagrams consist only of packages
• Packages group classes, allowing aggregation and association relationships
• Dashed arrows portray dependency relationships
• Changes in one package can require changes in another

Guidelines for Creating Package Diagrams

• Use package diagrams to logically organize designs
• Group classes with inheritance, aggregation, composition, or collaboration relationships
• Vertically support inheritance with superclasses above subclasses
• Horizontally place packages side by side for aggregation and association
• Dependency implies a semantic relationship between package elements
• Dependency direction goes from subclass to superclass, whole to part, and client to server
• Include actors and associations with use cases in packages to improve context
• Packages should have simple, descriptive names
• Packages should be cohesive, containing classes that belong together
• The more classes depend on each other, the more likely they are to belong in the same package

Creating Package Diagrams

• Set context, cluster classes, create packages, identify dependencies, lay out and draw the diagram

Verifying & Validating Package Diagrams

• Package diagrams, like other models, require verification and validation
• Package diagrams derive from class, communications diagrams, and CRUDE matrix
• Review identified packages from a problem domain perspective
• Base dependency relationships on message-sending from communications diagrams, CRUDE matrix entries, and class diagram associations

Design Criteria

• Good design balances trade-offs to minimize system cost over its lifetime
• Criteria includes coupling, cohesion, and connascence

Coupling

• Coupling refers to interdependence or interrelation of modules (classes, objects, methods)
• Higher interdependency means changes in one part can require changes in others
• Interaction coupling involves coupling among methods and objects through message passing
• Inheritance coupling relates to the tightness of classes in an inheritance hierarchy

Cohesion

• Cohesion refers to the single-mindedness of a module (class, object, or method)
• Method cohesion involves methods doing one thing only
• Class cohesion means a class represents only one concept
• Generalisation/specialisation cohesion addresses the suitability of the inheritance hierarchy, concerning how related the classes are within it

Connascence

• Connascence generalizes cohesion and coupling, combined with arguments for encapsulation
• Level-0 encapsulation: Encapsulation in an individual line of code
• Level-1 encapsulation: Combining lines of code into a method
• Level-2 encapsulation: Creating classes with methods and attributes
• Method cohesion and interaction coupling address level-1 encapsulation
• Class cohesion, generalisation/specialisation cohesion, and inheritance coupling address level-2 encapsulation
• Connascence addresses both level-1 and level-2 encapsulation

Design Strategies

• Custom development, package software, outsourcing are design strategies

Selecting a Design Strategy

• Business need, in-house experience, project skills, project management, and time frame help select a design strategy