prasad@dsv.su.se What is important to think about when making a domain model.
To make models which show how the system should
consider the reality in terms of concepts and relations among concepts. The concepts should be taken from the problem domain. One should not use class name and attribute of software classes not included in problem domain. Of course, a concept might become a software class in the design (this is one of the ideas behind using domain models.) The multiplicity has to constrain the domain model in a way which corresponds to the reality. Shift in Focus
• The requirements and object-oriented analysis
focus on learning to “do the right thing” (understanding the goals) • Design work stresses to “do the thing right”; that is, skilfully designing a solution to satisfy the requirements for an iteration • In iterative development a transition from requirements/analysis focus to design/implementation focus will occur in each iteration Software Architecture
An architecture is the set of significant decisions
about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization Architecture Simplified
• Software Architecture has to do with the large
scale • It describes the “Big Ideas” in the organization, motivation, constraints, patterns, responsibilities, and connections of a system Focus: Logical Architecture
• The large-scale organization of the software
classes into packages, subsystems and layers • Logical, because there is no decision yet about how these elements are deployed across different operating system processes or across physical computers in a network (see Deployment Architecture) Layers
• A layer is a course-grained grouping of classes,
packages or subsystems that has cohesive responsibility for a major aspect of the system. • Layers are organized such that “higher” layers call upon the services of “lower” layers, but not normally vice versa. Typical Layers • The User Interface – Graphical Interfaces, Windows • Application Logic and Domain Objects – Software objects representing domain concepts that fulfill application requirements, such as calculating a sale total • Technical Services – General purpose objects and subsystems that provide supporting technical services, such as interfacing with a database or error logging. – These services are usually application independent and reusable across several systems Strict or Relaxed
• In a strict layered architecture a layer only calls
upon the services of the layer directly below it – Common in network protocol stacks – Not so common in information systems • In a relaxed layered architecture a layer may call upon several lower layers. UML Package Diagrams
• Often used to illustrate the logical architecture of
a system. A layer can be modeled as a UML package • A UML package diagram provides a way to group elements (classes, other packages, …) • It is common to show dependency between packages so that developers can see the large- scale coupling in the system A UML Package Diagram Design with Layers
• Organize the large scale logical structure of a system
into discrete layers of distinct, related responsibilities. • Have a clean cohesive separation of concerns: – Lower layers – low level, general services – Higher layers – more application specific • Collaboration and coupling from higher to lower layers; avoid the other way around • The purpose and number of layers varies across applications and application domains ommon Layers in an nformation System Architecture Without Layers…
• Source code changes are rippling throughout the
system since many parts of system are highly coupled • Application Logic is intertwined with UI, so it cannot be reused with a different interface • General technical services are intertwined with more application specific logic, so they cannot be reused or easily replaced with a different implementation • It is difficult to divide work along clear boundaries for different developers. With Layers …
• Reduced coupling and dependencies
• Improved cohesion, clarity and reuse potential • Higher Layers can be replaced with new implementations (e.g. UI) • Lower layers contain reusable functions • Team development is aided by segmentation Domain Model and Domain Layer Relationship Partitions within a Layer
• Partitions represent a horizontal division of
relatively parallel subsystems of a layer • Layers of an architecture represent the vertical slices. Layers and Partitions Model-View Separation Principle
• Model (domain) objects should not have direct
knowledge of view (UI) objects – Do not connect or couple non-UI objects directly to UI objects • Domain classes encapsulate the information and behavior related to application logic – Do not put application logic in the UI objects’ methods. – UI objects should delegate requests for application logic to non-UI objects We M-V Separate to…
• Allow separate development of the model and UI
layers. • Minimize impact of requirements changes in the interface upon the domain layer • Allow new views to be easily connected to an existing domain layer (without affecting it) • Allow multiple simultaneous views on the same model object • Allow easy porting of the model layer to another UI SSDs, System Events, Layers
• SSDs illustrate system events, but hide the
specific UI objects • In praxis, UI objects will capture these system operation requests - usually with a rich client GUI or Web page • The UI layer objects will then forward (delegate) the request from the UI layer onto the domain layer for handling System Operations On to Object Design
• How should we design objects?
– Code From mental model to code. Design-while coding (rather discouraged) – Draw, then code Draw some UML, then switch to coding (our approach) – Only draw The tool generates everything from the diagrams (wishful thinking?) Static vs. Dynamic Modeling Dynamic Object Modeling
• Most of the challenging, interesting and useful
design work happens while drawing UML interaction diagrams – We think through the exact details of what objects need to exist and how they collaborate via messages and methods • Often we will be drawing interaction and class diagrams concurrently Other Techniques: CRC Cards
• Class Responsibility Collaboration cards
• Paper index cards on which one writes the responsibilities and collaborators of classes • Each card represents one class • A CRC modeling session involves a group sitting around a table, discussing and writing on the cards as they play “what if” scenarios with the objects – What the objects must do – What other objects they must collaborate with CRC Cards Sample CRC Cards