Analysis Paralysis We spend so much time thinking about the problem and making sure the next step is “perfect” there is a risk that we never actually make the next step. “Do you want it perfect or do you want it now?”
Designing a system is a process of discovery.
Faulty Assumptions In the second lecture we drew up the following detailed specification… The consultant sits at their desk with a stack of business cards and flyers. They pick up a business card and start to input the details into system. The first field they enter is the name of the company. While doing this the system looks up the company name to see if it is already on the system. The next field the user enters is the name of the contact. Whilst dong this, the list of contacts for that company is displayed such that if the contact is already on the system the user may move onto another business card. At this point the user should have the opportunity to update the details on the system should they note that some aspect has change e.g. address.
From this we drew up an initial event table… SubjectVerbObjectResponse ConsultantInputsCardData accepted by the system SystemChecksCardIdentifying duplicates ConsultantUpdatesCardNew data input
Resulting in the following initial use case diagram…
There is a problem Back to that red herring If we collected business cards like stamps then yes we would be interested in recording individual cards. What’s more important in our case isn’t the cards but the data they contain. We are interested in business intelligence on the companies and the people they employ.
Need to Revise the Specification The consultant sits at their desk with a stack of business cards and flyers. They pick up a business card and start to input the details into system. The user is interested in recording details of the individual and associated company. The first field they enter is the name of the company. While doing this the system looks up the company name to see if it is already on the system. The next field the user enters is the name of the contact. Whilst dong this, the list of contacts for that company is displayed such that if the contact is already on the system the user may move onto another business card. At this point the user should have the opportunity to update the details on the system should they note that some aspect has change e.g. address.
And the Event Table SubjectVerbObjectResponse ConsultantInputsCompany Name System produces a list of companies with that name SystemFindsCompanyProduces a list of companies with that name SystemListsEmployeesProduces a list of employees at each company ConsultantAddsCompanyCompany added to the system ConsultantAddsEmployeeEmployee added to the system ConsultantUpdatesEmployeeEmployee details updated ConsultantUpdatesCompanyCompany details updated
And the Use Case Diagram
Initial Stab at the Class Diagram
First Go at the Sequence Diagram Actors Objects Swim lines Messages
Important Questions to Ask Do we have an actor on the use case that matches the sequence diagram? Yes! Do we have a class that allows us to create the Companies object? Yes! Do we have methods in the class that are able to handle the messages? FilterByCompanyName – yes FilterByCompanyNo - no
Revise the Class Diagram
So What Data Comes Back? We may also find clues to the attributes
Objects must have relationships in the class diagram
Extending the Sequence Diagram Do we have an operation to support this message?
Revise the Class Diagram
What About Validation?
Modify the Use Case Diagram
Where to Place the Validation Method? Composition and Aggregation Revisited Composition Aggregation OrderOrder Line Has10..* Attributes Operations Attributes Operations CustomerAddress Uses11..* Attributes Operations Attributes Operations
Does this Make sense? Aggregation or Composition?
This is an Aggregation This will need extending to include the parameters
The Sequence Diagram
The Use Case Diagram
The Class Diagram
Is it right? Probably not yet But we now have a mechanism to cross check one diagram with another
Exercise