SeeS Overview
Joseph Flanigan 1990
DRFAFT
SeeS is a style of abstract syntax used to model the problem space characteristics of a computing system environment. The model details object-oriented analysis, design, and construction principles.
SeeS details a methodology to aid computer system architects in modeling object-oriented application environments. The name sees as an application solution tool originated with the photographer Ansel Adams' method of viewing a scene before taking a photograph, so that in his mind’s eye, he could see the finished print. Adam’s called his skill “the art of seeing.’ The computing system's object-oriented design principles are to make an application image that can be codified into an application presence. Consider SeeS to the camera that captures the problem scene into a tangible print for further processing.
Principles of Object‑Oriented Systems
Object‑oriented programming (OOP) is built on four foundational principles that help structure software into modular, reusable, and maintainable components. These principles are consistently identified across authoritative sources.
1. Encapsulation
Encapsulation means bundling data and the methods that operate on that data into a single unit (a class) and restricting direct access to the internal state.
Why it matters
• Protects internal data from unintended modification
• Enforces controlled access through public methods
• Reduces coupling and improves maintainability
2. Abstraction
Abstraction is the practice of hiding complex implementation details and exposing only what is necessary for using an object.
Why it matters
• Simplifies how objects are used
• Reduces cognitive load
• Allows developers to focus on what an object does, not how it does it
3. Inheritance
Inheritance allows a class to derive from another class, inheriting its attributes and behaviors.
Why it matters
• Promotes code reuse
• Enables hierarchical relationships
• Supports polymorphism
4. Polymorphism
Polymorphism allows different objects to respond to the same message (method call) in different ways
SeeS Formalism
I. Object-Oriented Productions
SeeS is a formalism for object-oriented design that uses an abstract syntax analysis style to detail abstract notations and production rules that define the class taxonomy.
A root class can have productions elements of classes, objects, methods, or messages.
Classes and objects may have forward or reverse relations,A along with associated
cardinality.
Any base class, by definition, has simple inheritance but may have multiple inheritance.
The canonical list defines a preference order for attribute resolution, with first to last being preferred.
Objects or methods can have signatures that are attribute lists or data structures.
Objects or methods can be polymorphic.
Methods can be public, private, or protected.
Comments can be added anywhere.
There is an external tag to identify a location for expanded descriptions, like a URL
II. Usage Concept
The use of object-oriented techniques in any problem domain involves analyzing the problem into objects and the actions performed on them.
Identified objects have defined relations between them.
Special types of objects, called classes, exist to minimize memory by clustering similar characteristics.
The basic science for clustering is called classification theory.
While the study of classification theory may yield refined structures, the practical application is more intuitive.
SeeS is a mechanism for capturing intuitive classification and providing a formal structure for refinement.
The attractive feature of the object-oriented proposition is that the results of analysis are a structure that describes a design.
The more comprehensive the structure, the more complete the design becomes.
This means that the more emphasis placed on the analysis, the more refined the design becomes.
The use of production rules provides the benefit of expansion in an algebraic sense to any level of refinement.
SeeS use of production rules allows the refinement to expand at a natural scope as domain information becomes available.
Structural alterations are made by changing productions according to the defined rules.
These rules are simple and easy to use.
SeeS capitalizes on people's intuitive classification by providing a technique for recording descriptions.
The descriptions can be block diagrams, entity/relationship models, outlines, Venn diagrams, programs, or other similar illustrations.
A SeeS' production reads as base class name "sees" subclass name, object names, method name etc.
A simple block diagram for an accounting system may have lower blocks called accounts receivable, accounts payable, income and expenses.
The SeeS' expression would read base class accounting system sees class accounts receivable and
class accounts payable and class income statement.
Base class income statement sees class income and class expenses.
III. Writing SeeS
The accounting system example in written basic document form can become verbose and unintelligible. Using the SeeS' notation, the logic is very understandable. The simplest SeeS' expression uses a construct, "::" a dot-dash-dot, as a separator. The left side of the separator is for the base class, and the right side is for the subclass. Left and right arrows enclose subclass names, indicating a production.
The accounting system example would have the SeeS' expression:
Accounting_System :: <Accounts_Receivable>
<Accounts_Payable>
<Income_Statement>
Income_Statement :: <Income>
<Accounting_System> <Expenses>
For ease of reading and expression construction, the left side is clearly separated from the right side. The construct <Accounting_System> in Income_Statement documents the base class from which the production originated.
SeeS is a production system where the named objects are production elements.
IV. SeeS Abstract Syntax Notation
a. Names beginning in upper case have productions
b. Names beginning in lower case are terminal
c. Quotes define literals
d. Comment begins with "/*"
e. The production separator is "::" and is pronounced sees
f. Parentheses are options
g. Ampersand means "and"
h. Vertical bar means "or"
-----------------------------------------------------------------------
---------------------------------------------------------------------
V. Examples
1. From Shlaer and Mellor, Object-Oriented Systems Analysis
pg 58 5.5.2 How to Model a (M:M) relationship
Appliance :: <Part>>*is_made_of // forward relationship
< . . . > Model_number
Appliance_manufacture
Appllance_type
Part :: Part_number
<<Appliance>*is_component_of //Many to Many
Part_manufacturer
Price
Description
This example reads: Appliance is made of Parts, and Part is
component of Appliances.
# How to Model Object-Oriented Problem Space
Modeling an object-oriented problem space is a systematic process of understanding a domain and translating it into objects, classes, and their relationships. Here's a comprehensive approach:
## The Modeling Process
### **Phase 1: Problem Understanding**
```
1. **Domain Analysis**
- Identify the system's purpose and scope
- Gather requirements (functional & non-functional)
- Define system boundaries (what's in/out of scope)
2. **Identify Key Stakeholders & Users**
- Who interacts with the system?
- What are their goals?
- What roles do they play?
3. **Discover Key Concepts**
- Extract nouns from requirements → potential objects/classes
- Extract verbs → potential methods/behaviors
- Identify real-world entities in the domain
```
### **Phase 2: Object Discovery & Definition**
```
4. **Identify Candidate Objects**
Look for:
- Tangible things (Car, Book, Sensor)
- Conceptual entities (Account, Reservation, Policy)
- Events (Transaction, Meeting, Alarm)
- Roles (Customer, Employee, Administrator)
- Organizational units (Department, Team)
- Interactions (Contract, Agreement)
5. **Define Object Responsibilities**
For each candidate object, ask:
- What does this object KNOW? (attributes/properties)
- What does this object DO? (behaviors/methods)
- What must this object remember over time? (state)
```
### **Phase 3: Relationship Mapping**
```
6. **Identify Relationships**
- **Association** ("uses" or "works with")
- **Aggregation** ("has-a" weak containment)
- **Composition** ("part-of" strong containment)
- **Inheritance** ("is-a" generalization)
- **Dependency** ("uses temporarily")
7. **Create CRC Cards** (Class-Responsibility-Collaborator)
```
Class: Order
Responsibilities:
- Calculate total
- Add/remove items
- Check status
Collaborators:
- Customer
- OrderItem
- Payment
```
```
### **Phase 4: Dynamic Behavior Modeling**
```
8. **Identify Use Cases/Scenarios**
- "Place order"
- "Cancel reservation"
- "Generate report"
- Map objects participating in each scenario
9. **Sequence/Collaboration Diagrams**
- Show how objects interact over time
- Identify messages/method calls
- Reveal needed interfaces
10. **State Diagrams for Complex Objects**
- Model objects with significant state changes
- e.g., Order: [Pending → Processing → Shipped → Delivered]
```
## Practical Techniques & Tools
### **1. Linguistic Analysis**
```text
Requirements: "Customers place orders for products.
Each order contains multiple items with quantities.
The system calculates totals and manages inventory."
Nouns → Candidates: Customer, Order, Product, Item, Quantity, System, Inventory
Verbs → Behaviors: place, contains, calculates, manages
```
### **2. Use Case-Driven Modeling**
```
Use Case: "Borrow Book"
Actors: Member, Librarian
Main Flow:
1. Member presents book
2. Librarian scans book ISBN
3. System checks member's loan limit
4. System records loan with due date
5. System updates book status
Objects identified: Member, Librarian, Book, Loan, System
```
### **3. CRC Card Workshop**
```text
┌─────────────────────────┐
│ Class: LibraryBook │
├─────────────────────────┤
│ Responsibilities: │
│ • Know title, author │
│ • Know current status │
│ • Calculate due date │
│ • Validate renewability │
├─────────────────────────┤
│ Collaborators: │
│ • Loan │
│ • Member │
│ • Catalog │
└─────────────────────────┘
```
### **4. Event-Storming**
- Identify **domain events** (past-tense verbs):
`OrderPlaced`, `PaymentProcessed`, `InventoryReserved`
- Identify **commands** that trigger events
- Identify **aggregates** that handle commands
- Identify **policies/reactions**
## Modeling Principles & Heuristics
### **Object Identification Heuristics**
```
1. **Abstraction Heuristic**
- Does it represent a coherent concept?
- Is there a clear "single responsibility"?
2. **Encapsulation Heuristic**
- Does it have data that belongs together?
- Does it have behaviors that naturally operate on that data?
3. **Persistence Heuristic**
- Would this need to be stored/retrieved from a database?
- Does it have identity that persists over time?
4. **Collaboration Heuristic**
- Does it need to work with other objects?
- Does it delegate responsibilities appropriately?
```
### **Relationship Guidelines**
```yaml
Inheritance (IS-A):
- Check Liskov Substitution Principle
- True taxonomic relationship
- Avoid: "Role" inheritance (prefer composition)
Composition (HAS-A strong):
- Part cannot exist without the whole
- Lifecycle bound together
- e.g., Room → Building
Aggregation (HAS-A weak):
- Part can exist independently
- Lifecycle independent
- e.g., Player → Team
Association (USES):
- Temporary relationship
- Method parameter or local variable
```
## Common Modeling Patterns
### **Pattern 1: Transaction Pattern**
```
Order ──┐
├─ OrderLineItem ─── Product
Payment ─┘
```
**When**: Modeling purchases, reservations, bookings
### **Pattern 2: Role Pattern**
```
Person ─┬─ Customer
├─ Employee
└─ Supplier
```
**Alternative**: Composition over inheritance
```
Person ── Role (CustomerRole, EmployeeRole)
```
### **Pattern 3: Observer Pattern**
```
Sensor ──○→ Alarm
└→ Logger
└→ Dashboard
```
**When**: One object's state changes affect multiple others
### **Pattern 4: Composite Pattern**
```
Menu
/ \
MenuItem SubMenu
/ \
MenuItem MenuItem
```
**When**: Part-whole hierarchies with uniform treatment
## Refinement & Validation
### **Ask These Questions**:
1. **Cohesion**: Does each class have a single, clear purpose?
2. **Coupling**: Are dependencies minimal and explicit?
3. **Completeness**: Can all scenarios be executed?
4. **Extensibility**: Can new features be added easily?
5. **Clarity**: Would a domain expert understand the model?
### **Common Pitfalls to Avoid**:
- "God Objects" (classes doing too much)
- "Anemic Domain Model" (objects with only data, no behavior)
- "Inheritance for code reuse only" (violates IS-A)
- "Over-normalization" (too many tiny classes)
- "Circular dependencies" (A depends on B, B depends on A)
```
## Progressive Refinement Steps
### **First Pass: Domain Objects Only**
```
Library System v1:
Book, Member, Loan, Librarian, Fine
```
### **Second Pass: Add Behavior**
```
Book:
- borrow()
- return()
- isAvailable()
- calculateDueDate()
Member:
- borrowBook(book)
- returnBook(book)
- calculateFines()
```
### **Third Pass: Relationships & Interfaces**
```
┌─────────┐
│ILoanable│
└───┬─────┘
│
┌──────┴──────┐
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Book │ │ DVD │
├─────────────┤ ├─────────────┤
│+borrow() │ │+borrow() │
│+return() │ │+return() │
│+getDueDate()│ │+getDueDate()│
└─────────────┘ └─────────────┘
```
### **Final Pass: Design Patterns & Optimization**
```
Add Factory Pattern for Loan creation
Add Strategy Pattern for fine calculation
Add the Repository Pattern for data access
```
## Validation Through Scenarios
**Test your model with these questions**:
```
Scenario: "Member wants to renew a book."
1. Which object receives the "renew" message?
2. What preconditions must be checked?
3. What state changes occur?
4. What collaborations are needed?
5. What exceptions might occur?
```
## Modeling Artifacts Checklist
- [ ] **Domain Model** (conceptual objects & relationships)
- [ ] **Use Case Diagrams** (system functionality)
- [ ] **Class Diagrams** (static structure)
- [ ] **Sequence Diagrams** (dynamic interactions)
- [ ] **State Machine Diagrams** (object lifecycle)
- [ ] **Package/Component Diagrams** (high-level organization)
- [ ] **CRC Cards** (responsibility assignment)
## Pro Tips
1. **Start with behavior, not data**: Ask "what does this object do?" before "what data does it have?"
2. **Model from multiple perspectives**: User view, data view, system view
3. **Iterate rapidly**: Create quick sketches, validate, refine
4. **Use domain language**: Classes and methods should speak the domain's language
5. **Keep it simple**: The simplest model that works is usually best
6. **Validate with scenarios**: Walk through key use cases with your model
## 🎓 Example: E-commerce System Modeling
**Step 1: Extract key concepts from requirements**
```text
Requirements include:
- Customers browse products
- Add products to the shopping cart
- Place orders with the shipping address
- Make payments
- Receive order confirmations
- Track shipments
Key nouns: Customer, Product, Cart, Order, Address, Payment, Confirmation, Shipment
```
**Step 2: Initial object identification**
```python
class Customer:
# Attributes: name, email, addresses
# Methods: place_order(), view_orders()
class Product:
# Attributes: name, price, sku, inventory
# Methods: is_available(), update_inventory()
class ShoppingCart:
# Attributes: items, customer
# Methods: add_item(), remove_item(), calculate_total()
class Order:
# Attributes: order_number, date, items, status
# Methods: calculate_total(), cancel(), ship()
```
**Step 3: Refine with relationships**
```
Customer "places" Order (1-to-many)
Order "contains" OrderLineItems (1-to-many)
OrderLineItem "refers to" Product (many-to-1)
Order "has a" ShippingAddress (composition)
Order "has a" Payment (aggregation)
```
**Step 4: Add behavior through scenarios**
# Scenario: Customer places order
customer = Customer("John")
cart = ShoppingCart(customer)
cart.add_item(product1, quantity=2)
order = customer.checkout(cart, shipping_address, payment_method)
# Triggers: inventory check, payment processing, email confirmation
```
The key is to **iteratively discover objects, assign responsibilities, define relationships, and validate through scenarios** until you have a coherent, working model of your problem space.
No comments:
Post a Comment
Thank you for your comment.