Use Cases to Classes in a PHP MVC Framework

[stoutie]

Any folks out there have a good understanding of OOP, UML, PHP and MVC? Quite a whiz-bang combination. I don't know many people that do. I've come to adopt all of these things as part of the work I do.

I'm planning a web application right now, and taking the opportunity to boil the planning phase down to a science. But I'm stuck. I have a good idea of how I want to start planning, and where I need to end up, but the stuff in the middle is the problem.

I really have never been comfortable with the whimsical way classes and their methods are chosen.

I should fill you in on a few things:
I'm working with a PHP framework that uses components and scripts. Each component consists of a model, view and controller class. The component may also have a templates folder. The controller provides the methods for the application to interact with the component. The method provides the controller with the methods to interact with the data. The view provides the controller with the methods to interact with the templates, presentation, or output formatting. Now the script utilizes the components to satisfy the request. The script to include is determined by the first segment of the request url. The scripts may utilize multiple components.

Now, where I'm starting is with the planning process. I want to boil it down to a science that can be repeated quickly and efficiently. I start with use case diagrams. Then for each use case I develop narratives. Then, I develop use case scenarios using activity diagrams.

At this point, I'm thinking I should have enough information to start defining components, and the methods on their controllers, models and views.

I think it should be a simple matter of looking at the use case scenarios activity diagrams and assigning each activity performed by the application to a method on either the model or view of the appropriate component.

Then the controller would get a method for each use case. But decided that since a use case could involve multiple components, the component should not be responsible for the entire use case. It seemed more appropriate to assign the use case to a script in the scripts folder.

So that's where I'm at. I need a good discussion group to hash out some theories about how to get from the use case scenarios to the scripts, the components they use, and the methods on the components' models, views and controllers.

Maybe a case study would help uncover some of these theories? How about we start with a simple blog?

Use cases:
user can create post
user can view post
user can edit post
user can delete post(s)
user can publish post
user can save post as draft
user can mark posts public/private

 

[jmeckley]

it sounds like you are talking about "user stories", a concept common in agile/scrum/lean project management. a use case doesn't necessarily align 1:1 with a controller action. for a simple example like blog it would, but for a more complex site, like amazon, that's not the case.

it would also depend on the context of the story. if you consider a webpage a single context, then a single controller/method per use case wouldn't make sense. if you are talking about the different components on the webage (navigation, shopping cart, product information, similar product listing, sitemap) then each component could be a single user story, giving you the 1:1 correlation between controller action and use case.

there is a lot existing information on project management already. It's not specific to any one language (not should it be). Along with literature on defining user stories I would recommend the conceptual view points of udi dahan. His focus is the .net framework, but the concepts he talks about are universal. They may help you formulate your concepts more clearly.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[stoutie]

I really felt like you understood what my question was! What a relief!

I'll check out udi dahan's concepts.

Could we keep this dialog open, as I know I will probably want to come back for more?

It's really about figuring out those rules to follow. When to assign the use case to what. How far to split the activities of a use case down before assigning as methods to a class. How to identify good classes. Etc.

Like I said, I'll check out udi dahan's stuff and come back here.

Thanks!

 

[jmeckley]

to clarify: my reference for udi dahan was meant to think about how to structure the application. this in turn will influence how you define user stories. there isn't a direct relation to udi's material and your work on defining user stories.

I also wouldn't get too caught up in definitive rules on what a user story is and how to define it. start small and gradually build up. if you find something isn't working for you, don't use it. just like coding... there isn't one right way.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[stoutie]

While there isn't one right way, it is helpful, especially when working with a team, to develop conventions, both in planning, and in coding, to establish a common base of thought and consistent, predictable results. Some call it OCD. Some call it smart!

I'm seeking to discover the most effective conventions for forming class definitions during the planning phase. I'm looking for the conventions that will lead out of the use case model to the class definitions. I've heard of the domain model and the design model.

From what I understand that the first step to developing the domain model is to identify the nouns in the requirements documents. These nouns become the classes. But as the domain model develops, some classes may be refined while others are eliminated. There is also an architectural model. I understand the design model works off of the domain model and architectural model towards an implementation model.

This sounds like the direction I need to go.

Any idea where I can find top notch materials about these different models?

 

[jmeckley]

I know where you're coming from. I consider conventions and rules are different things, conventions guide you while rules are hard and fast. conventions are discovered, but evolve overtime. it's not a once and done event.

I've heard of the domain model and the design model

. Now we are getting into technical design which gets away from defining stories and use cases. the two can work together, but they are different things.

the first step to developing the domain model is to identify the nouns in the requirements documents

this is the crudest/most primitive model, yes. it's probably a good starting point too, if you haven't worked with a domain model before.

The Domain Driven Design by Eric Evans (The Big Blue Book) is considered the bible of how to design a domain. For online resources Udi Dahan is the best online resource I have found for this material. I also like Los Techies. They have alot of posts on SOLID design principles. the language of choice is c#, but the concepts apply to any OOP language. If you could find code examples of the SOLID design principles in php or ruby it may be easier to understand.

another good book, geared more toward software infrastructure, is Patterns of Enterprise Application Architecture by Martin Fowler and Release It! by Nygard. code samples in java, but the concepts are universal.

the "domain" is the business model. the objects, methods and events should mirror the language of business experts. concepts like customer, order, address and money. not row, tables, strings and decimals.

the view model is a contextual projection of domain.

architectural model - I believe they are referring to the infrastructure. this layer/components/thing is the glue that holds the application together. things like MVC, templating engine, ORM/data access, message bus, event broker, object resolution, etc. it may even define the conventions used within the code to reduce mundane tasks.

For a majority, 95%, of the applications out there you won't need most of this. most of the time it's simple forms over data. but having some knowledge about these concepts will help you make an educated decision about if, when and where to apply them.

finally, if this is new to you and your team, try to implement all of this all at once will be a disaster and fail. there is just too much to take in and too much cultural change. you will need a coach/project lead who has done this before to help guide the team (from a project management view point). Also, tackling one concept at a time (whether it be coding or project management) will ensure a better chance of success.

Jason Meckley
Programmer

faq855-7190
faq732-7259

 

[stoutie]

Yet again, thanks.

I'm eager to glean from the experience of these frequently mentioned authors.

This is good stuff. Currently, I'm working solo and thought it would be a perfect time to begin deepening this aspect of my work.

I visited the bookstore today looking for books on these topics. I wish I'd known to look for the few you mentioned. Anyways, I got to talking with a guy there and we had a pretty good conversation about unblocking creativity. I use a journal to capture and elaborate on project requirements. He suggested I use a different color of ink when I get stuck. He also suggested I buy some more fresh journals.

I tried out his advice. With more journals sitting by, the pressure to make every jot and tittle on every page something of profound importance is eliminated. And switching to a different color of ink helps separate formal time from creative-exploration time. I found that my paralysis lifted and I successfully conceptualized how a particular component would be built, satisfy a the use case, and fit into the framework I'm using.

Sometimes the answer is so simple we'd never think of it.

The planning process is a creative process, the goal of which is to conceptualize the solution, and hopefully correct any problems before they are set in code. Just have to remember that and I think I'll be fine.