Sparx Systems Forum
Enterprise Architect => Uml Process => Topic started by: ASP on June 20, 2007, 06:47:15 pm
-
Hey, folks. I searched the forum but was unable to locate any thread that answered my question; so, here it goes.
First, I'm new to UML and EA, so bear with me. I'm working on a CD cataloging application, and I figured the project would provide me with a good opportunity to learn a subset of UML (I've eliminated any business process modeling, as this does not apply to this project).
First, here is an EA-related question as applies to extension points. I'll briefly describe the use cases I've defined.
The End User (an actor) needs to Add a CD (the use case) to the catalog. Adding a CD can be accomplished in one of three ways: manually, guided, automated.
Normally, one adds the CD details manually by completing some form. Optionally, the end user may wish to add the details via a wizard, which guides the user in the entry process. Regardless of which method of input is selected, there is another option that allows the end user to query an online music database in order to download CD details, hence automating the process as much as possible. However, this third approach is only presented once the end user chooses to enter information either manually or with the wizard.
I've added extension points to the "Add a CD" use case.
Use Case: Add a CD
Extension Points: Guided Entry, Automated Entry
Use Case: CD Input Wizard
Extension Point: Automated Entry
Use Case: Download CD Details from Online Music Database
Extension Points: n/a
The "CD Input Wizard" & "Download..." use cases extend "Add a CD", and the "Download..." use case additionally extends "CD Input Wizard".
Here's the problem. When extension points are defined in EA, they are stored in lexicographical order, and there is no option to reorder them. Therefore, one is forced to position the use cases having the extended association in a way that visually complies with that order. Is it possible to reorder extension points in a use case?
Far more important, does my description correlate to good use case design practices? For example, I could just as easily approach the problem as follows, without extension points.
Use cases:
=========
Add a CD
Manual Entry
CD Input Wizard
Download...
The "Add a CD" is a base use case than generalizes the "Manual Entry" & "CD Input Wizard" use cases. The "Download..." use case then maintains a dependency relationship with the "Manual Entry" and "CD Input Wizard" use cases. This way, we remove the extension points altogether, and the associations provide a more direct traceability to the classes implied by these use cases.
At this point I prefer the extension point route, because I don't believe this simple collection of use cases justifies the implication to define an "Add a CD" (possibly abstract) class. Naturally, the generalization associations in the use cases do not force one to create the classes I mentioned in a class diagram, but the implication is there, where there is no such implication using extension points.
Thanks for your feedback.
-
My recommendations:
Keep your Uce Case Model as simple as possible.
Generalization - don't use it at all.
Extension - use as least as possible. Originaly it was designed for the situation, where there is one completly realized UC and the analyst want to extend it with new UC without touching the old one.
That means the extended UC completely doesn't know anything about the extending UC. Extension point has to refer to something inside the extended UC (Automated entry is not known inside Add a CD).
Inclusion - pretty simple to understand, you can use it. But don't over use it. An UC has to have a goal and bring a value to the actor. Think about it in this way - An actor has to be happy, when the UC finished.
You can have different levels of UC model. One with UCs that bring really benefits to actors. And second with UCs decomposition using inclusions - common subfunctions are made separate UCs and are included in other UCs.
Alternate scenarios - very usefull and quite simple to understand. I use them nearly in every UC. Unfortunately there is no automatic step numbering in EA. This made referencing basic scenario from alternate scenario very difficult. BUt nevertheless I use alternate scenarios because they are the most effective way to express an UC. With alt. scenarios you can have one UC with one goal, one actor, one precondition and yet several scenarios. It looks nice from outside - just one UC, and the complexity is inside the UC.
-
Peter,
Thanks for your reply. With respect to your last point - alternate scenarios - I am actually documenting the various scenarios within the use cases. However, I see your point. If I understand you correctly, you suggest I define a single use case - namely, "Add a CD" - and provide any precondition(s) and all scenarios in this use case. This simplifies the visual design and encompasses all "adding a CD" functionality into one use case.
As I see is, this would result in a decent number of scenarios for this use case, because there are several options available: manual, guided and automatic. For example, manual entry is the "basic path", whereas guided entry is an "alternate" path. Other "alternate" paths occur with the two aforementioned path, each with the additional option of used automated entry, since the purpose of automated entry is simply to assist filling the CD details regardless of which form of data entry is initially chosen.
Additionally, I need to account for scenarios that describe unsuccessful attempts to "add a CD" in the various scenarios described earlier. At what point would you consider breaking out use case functionality when presented with a large number of scenarios?
Continuing, I suppose each scenario can then be further described with its own activity and sequence diagrams, which provide different views.
My largest concern, however, is to eventually translate these scenarios into a PIM. Would you, for example, also create state machine views in order clearly specify the operations performed by class functions/methods?
Thanks for your feedback.
-
I don't have any exact number of alt. scenarios which I consider "too many". But you are right, there is a limit.
IMO Use Cases are something like a story and it's not a good practice to convert scenarios directly into code.
If you analyze each UC and describe it using sequence, activity and state machine diagrams, it means you are creating a PIM. Sequence and state machine diagrams are not possible without some classes (usually) and with classes, you have class diagrams.
-
> Sequence and state machine diagrams are not possible without
> some classes (usually) and with classes, you have class
> diagrams.
Well, yes. Perhaps I was unclear in my last post. I am developing this software within an object-oriented design paradigm, which is why I decided to architect the solution using a UML case tool.
I'm quite comfortable with object-oriented programming. However, since I'm a newbie to both UML and EA, the greatest learning curve is understanding (or obtaining information) for case studies that robustly implement various methodologies. As for now I am focusing exclusively on the Unified Process. While there are plenty of sources that describe the Unified Process (and its numerous derivatives) in detail, I've yet to find any sources that walk through serious case studies (of fictitious companies, mind you).
In short, my problem is not understanding UML and EA; rather, it's understanding how to effectively use UML to architect a complete software solution. Again, I'm deliberately avoiding business modeling.
In my first go-around I began my project by textually defining the features I wanted, after which I dove into designing a Use Case model for the system. However, after some additional reading, with every source having its own take on recommended procedures, I decided to start again with a requirements model. Currently, I am creating requirement diagrams that trace requirements to use cases, which I linked together in the relationship matrix.
In terms of continuing along a path to eventual class design and implementation, I figured the next step is to create communication, sequence and state machine diagrams for the various scenarios in my use cases. However, I quickly hit a wall, because these interaction diagrams would require classes and or instances of classes that I have not yet defined.
See where I'm going?... lol. Right now, I'm wading through the dark in quicksand. What I really need is a sturdy branch, so someone can drag me along the right path.
Thanks again for your feedback.
-
In terms of continuing along a path to eventual class design and implementation, I figured the next step is to create communication, sequence and state machine diagrams for the various scenarios in my use cases. However, I quickly hit a wall, because these interaction diagrams would require classes and or instances of classes that I have not yet defined.
To paraphrase an Australian political slogan from 30 years ago...
"It's time!"
The domain (computationally independent, or conceptual) model is chock-full of classes. They're just not implementation classes. I model these in a special language defined to EA called Conceptual.
HTH,
Paolo
-
To paraphrase a Geico commercial...
"Yeah, I'd like to respond... uh, what?"
-
It's time to start defining the classes...
Paolo
-
> It's time to start defining the classes...
Lol... okay.
For clarification purposes, I want to be sure I understand your response properly. Please correct me if I have misinterpreted you.
First, I have not yet completed the Use Case model for the entire system. However, I assume your response makes the assumption I would have done so already, and it is your suggestion that I next design my classes before creating sequence, state chart and other diagrams derived on the Use Case scenarios.
That sounds reasonable, but this still begs the question regarding UML. If the purpose of UML is to visually model a object-oriented application (in this case) such that one can define a system's interactions before implementing the system, don't we have a chicken vs. egg situation? Let me define the term implementation. I am not referring to code implementation of the class model. In the context of UML, I use the term implementation (perhaps not the right term) to describe the process of designing a PIM based around all the interactions within the proposed system as noted by the various structural and behavioral diagrams and the various system views.
In other words - again, maybe I'm wrong - in terms of designing an object-oriented application, I thought UML serves to architect the system in a way that helps to establish a solid class design model. Given this understanding, I would consider the PIM model (and, subsequently, any PSM models) would essentially be almost self-describing based on the rigorous work done in architecting the system (ie, application, in this case).
Back to the chicken vs. the egg. In your response it sounds like you are advocating class design well before the aforementioned rigorous architectural considerations. You may ask, how would one otherwise create a sequence diagram, for example, without the existence of a class model?
Here's my take. I'll try to lay out my explanation using one of the scenarios for my "Add a CD" Use Case, using a sequence diagram.
Use Case: Add a CD
Scenario: Manual Entry - Success
1. End User activates a command to Add a CD
2. Fills in CD details data entry form
3. Clicks the "Save" button
The corresponding Sequence Diagram...
The left-most element is the actor "End User". The next element to the right is signified by a "boundary" element called "Add a CD Data Entry Screen". The last, right-most element, is a "control" element called "Manage Completed Data Entry".
An "Add a CD" message is sent from "End User" to "Add a CD Data Entry Screen". A "Click Save" message is sent from "Add a CD Data Entry Screen" to "Manage Completed Data Entry". "Manage Completed Data Entry" returns a "Save Result" message to "Add a CD Data Entry Screen". "Add a CD Data Entry Screen" returns a "Save Result" message to "End User".
The sequence diagram clearly shows the steps for this scenario, yet it does not rely upon any predefined class model. Rather, the messages abstract the intended operations of a class model, and the elements abstract the class model classes and/or class instances. In fact, the messages themselves neither have parameters, nor do they return anything. In other words, this is an example of my understanding of UML. That is, first focus on architecting a solution (eg, this sequence diagram) without concern for implementation details (eg, sequence elements & messages abstracting classes and their operations).
My point is that a rigorous architecture will clearly suggest the class model, rather than requiring a class model as a prerequisite to the architectural design. Of course, once the class model is designed, then implementing the details for it and all the related diagrams then becomes an iterative process, but that is to be expected in the Unified Process methodology.
Again, this is new to me, so I truly appreciate constructive criticism and alternative viewpoints on this topic.
Thanks again.
-
If the purpose of UML is to visually model a object-oriented application
That is not the only purpose of the UML. The UML is also used much earlier in the SDM than modeling an O-O application. It is, for example, initially used to model the problem/opportunity domain and for Solution Requirements modeling.
First, I have not yet completed the Use Case model for the entire system. However, I assume your response makes the assumption I would have done so already, and it is your suggestion that I next design my classes before creating sequence, state chart and other diagrams derived on the Use Case scenarios.
I'll let Paolo speak for himself, but personally I would not make that assumption.
I'm not exactly sure of your SDM nor your position within it. However...
Use Cases at the CIM level, model how the elements of the stakeholder's external environment interact with the stakeholder's domain; e.g., customers, suppliers, regulatory agencies interacting with a business. I would ask if you have created the CIM model and developed class specifications for the domain level objects?
Have you developed a Requirements Model that illuminates both the functional and non-functional requirements of the PIM? Have you identified the business goals of the various actors? These need to be articulated before the interactions, as you describe them, may be identified.
It would seem prudent to develop PIM level Use Cases that focus on the business goals of the stakeholders and not PSM level Use Cases that focus on CRUD activities such as your Add_A_CD. The Use Cases are, themselves, classes that are next defined through Protocol State Charts using the attributes and behaviors of the domain level objects.
Application Use cases come into play at the start of the PIM modeling process, but are driven by the earlier CIM and requirements models.
I reserve the term Architecture for the design that forms the basis of the PSM.
Where are you?
Jim
-
> The UML is also used much earlier in the SDM...
I plead ignorance. SDM?
> I'll let Paolo speak for himself, but personally I would not
> make that assumption.
Fair enough.
> Use Cases at the CIM level, model how the elements of the
> stakeholder's external environment interact with the
> stakeholder's domain; e.g., customers, suppliers,
> regulatory agencies interacting with a business.
CIM? (content information management?) As stated elsewhere in this thread, I chose to exclude any business modeling in this project.
> Have you developed a Requirements Model that illuminates
> both the functional and non-functional requirements of the
> PIM?
I haven't yet developed a PSM, let alone any PIMs. Ultimately my target language is C++, but I will develop an PSM so I may more easily port to other languages. As for the requirements model, thus far, I've only developed the functional requirements for the system but have not worked on any non-functional requirements.
> Have you identified the business goals of the various
> actors?
(Business modeling deliberately not considered in this project)
> It would seem prudent to develop PIM level Use Cases that
> focus on the business goals of the stakeholders and not
> PSM level Use Cases that focus on CRUD activities such as
> your Add_A_CD.
Well, again there are no business goals for this app. More ignorance on my part... "CRUD"?
> I reserve the term Architecture for the design that forms
> the basis of the PSM.
Yes. That was one of my points, although I may be wrong on "how to get there", so to speak.
> Where are you?
Searching and seeking for considered answers like yours... lol.
Again, thanks to everyone for your feedback. Please keep it coming; I can use the help.
-
Just a quick note as I'm on my way to bed.
CIM = Computationally Independent Model [from the MDA]
SDM = System Development Methodology
CRUD = Create, Read, Update, Delete (PSM abstraction level stuff)
(Business modeling deliberately not considered in this project)
Then I don't know what your doing and I don't think I can help you. Watch out for scope creep.
-
Thanks for clarifying the acronyms.
> Then I don't know what your doing...
I thought I made it clear in my posts to this thread. Very simply, I'm designing a single-user music cataloging application using object-oriented programming techniques. I'm new to UML & EA; I'm not interested in including any business modeling for this project.
> ...and I don't think I can help you.
That's okay. I appreciate your contributions.
-
Thanks for clarifying the acronyms.
> Then I don't know what your doing...
I thought I made it clear in my posts to this thread. Very simply, I'm designing a single-user music cataloging application using object-oriented programming techniques. I'm new to UML & EA; I'm not interested in including any business modeling for this project.
> ...and I don't think I can help you.
That's okay. I appreciate your contributions.
Hi ASP (I really prefer to converse with people rather than acronyms ;)),
You're right and your wrong...
You are (absolutely) right to try and keep as much as possible as abstract as possible for as long as possible.
You are wrong in that Classes don't exist (if I understand you correctly) at other than the PIM and PSM levels.
As Jim says (and he's correct in suggesting that I, too, wouldn't have made the assumption) UML is MUCH more than a mechanism for constructing PIMs and PSMs. The control elements you describe are classes - they're just not at the same level as code. The actors you describe are classes... You can use UML to provide any level of abstraction you require. In fact I've proposed/defined two more layers of models surrounding the OMG ones: The DIM - Domain Independent Model (one level of abstraction above the CIM) and the PSI - Platform Specific Implementation Model (a variant of the PDM) - which we use as the Design Model which we ship to our developers - then we reverse engineer the code they develop into the PSI and compare and contrast the two.
Does that clarify things for you? If not, try the OMG MDA site - which might help. Otherwise, like Jim there are insufficient points of commonality in our understandings of your problem that we really can't be of much further help.
TIP: Domain (Computationally Independent) Models are NOT synonymous with Business Models.
Perhaps others can help. If you don't get any other responses then (since you say you are new to UML) it may be that you are experiencing a scotoma.
Paolo
-
Paolo,
> Hi ASP (I really prefer to converse with people rather than
> acronyms...)
My apologies. However, I prefer it this way, and I'd rather not get into details.
> You are wrong in that Classes don't exist (if I understand
> you correctly) at other than the PIM and PSM levels.
Yes, you understood me correctly.
> The control elements you describe are classes - they're
> just not at the same level as code. The actors you
> describe are classes... You can use UML to provide any
> level of abstraction you require.
Naturally. It is this level of abstraction that makes UML so attractive. Still, I fail to see the reason why it is necessary to define classes at this stage of the game. In fact as I continue to work on this project, I feel this is ever the case. For example, I've completed several sequence diagrams that reflect scenarios in a couple of different use cases. Thus far, in each diagram I have utilized the "boundary", "control" and "entity" elements. Each element represents a concept that will eventually be a class or series of classes. For example, one boundary element refers to the concept of modifying the details of a CD that exists in a database, using a windowed form. One might choose to define a class or some instance of a class for this element, but with closer analysis, this may not be the best idea. For instance, one could opt to define one or more GUI-related classes, error-handling classes, data-marshalling & serialization classes, and so on. I'd rather worry about that level of detail much later, as it clutters the design process at this early stage. Instead, why not simply use a "boundary" element and move on to the next item? Further, I deliberately chose the "boundary", "control" and "entity" elements, because they are typically used to connote an MVC design pattern, where the boundary is a "view", the control is a "control", and the entity is a "model". This is the level of abstraction that makes UML so pretty.
> Does that clarify things for you?
> ...there are insufficient points of commonality in our
> understandings of your problem that we really can't be of
> much further help...
> If you don't get any other responses then (since you say
> you are new to UML) it may be that you are experiencing a
> scotoma.
No. Admittedly, I am not entrenched in this technology; yet, I'm willing to learn.
An aside... Technical forums are best left for technical responses. Clever verbal snipes only serve to disrupt the spirit and good will of the online community.
Perhaps the administrator(s) of this forum would consider partitioning it into levels of expertise. Those who wish to post and respond could then contribute accordingly. I will place this suggestion in the forum.
-
An aside... Technical forums are best left for technical responses. Clever verbal snipes only serve to disrupt the spirit and good will of the online community.
Where was the clever verbal snipe?
I try to be very precise in my responses... You are invited to observe my postings over the last couple of years.
Jim has said he's had trouble understanding where you're coming from. I'm in the same boat...
It seems to us (and I'll speak for Jim here - he will correct me if I'm not saying what he would) that your view of how UML works and our (hopefully, more mainstream) view differ sufficiently that we can't actually align our metamodels.
Speaking for myself, now, I believe I have an inkling of why you're having problems (and thus posted in the first place), but since you don't seem to be "getting it", it's really difficult to get it across. It sounds a bit to me like a paradigm shift problem. There's usually a gap that has to be crossed in one step to complete the paradigm shift. Unfortunately, the gap can't be crossed in more than one step.
As I said before, others may be able to help. Jim and I have tried - obviously, we're not able to.
No malice intended.
Paolo
-
I agree with all that Paolo has said. I feel your "clever snipe" accusation is an affront to the honest attempts we have made to help you, so this will be my last post to this thread.
I'll leave you with the following thoughts:
- At some point, the topic of this thread changed from the UML to a methodology discussion
- I understand what you're trying to build as an application; what I did not understand was your development methodology.
- Paolo and I model application systems that are industrial strength with issues too complex for anyone to hold in their mind at one time. Development projects for industrial strength systems have high risks that justify DIM/CIM modeling and involve hundreds of use cases.
- I suggest that the risks associated with your CD Catalog application are too low for you to see the value of that which we are recommending for inclusion in your methodology.
I wish you well.
*POOF*
-
> Where was the clever verbal snipe?
"If you don't get any other responses then (since you say you are new to UML) it may be that you are experiencing a scotoma."
Merriam-Webster: "a spot in the visual field in which vision is absent or deficient"
Surely, you could have expressed yourself more eloquently, rather than basically telling my I have a blind spot and "don't get it."
I repeat what I stated in my last post. Forums, especially technical forums, are about helping each other in earnest. I appreciate your attempts, but the fact that I still "don't get it", in your mind, is just as much a testament to my not understanding the issues as it is your not being able to effectively answer a question.
Granted, you seem to be well-versed on the subject, though I am not yet capable of ascertaining how well-versed you are, since I am new to this material.
Also, I'm impressed by your proposing/defining additional layers of models around the existing OMG models. However, that is irrelevant to my question.
I've made an honest attempt to pose a serious question, and I've done so with examples. I trust there are others who have similar questions but are hesitant to post them, because they do not wish to be embarrassed by "gurus".
I still appreciate your attempts, and I thank you for your efforts. I am sure there are members here and in other forums who are both knowledgeable and willing to provide helpful assistance that remains on point, without the condescension. Heck, I expect to fully from my scotoma, once such members respond with clear and concisely targeted answers, so that even I can see the solution. (...and I bet they'll be humble, too...)
-
jeshaw2...
> I feel your "clever snipe" accusation is an affront to the
> honest attempts we have made to help you, so this will be
> my last post to this thread.
Then you won't mind my responding. If interested read my response to Paolo regarding the snipe.
> At some point, the topic of this thread changed from the
> UML to a methodology discussion
From my initial post to this thread...
"First, I'm new to UML and EA, so bear with me. I'm working on a CD cataloging application, and I figured the project would provide me with a good opportunity to learn a subset of UML (I've eliminated any business process modeling, as this does not apply to this project)."
From that point forward, methodology (namely, the unified process) has been integral to this discussion, and you would see that if you've bothered to read my posts.
> I understand what you're trying to build as an
> application; what I did not understand was your
> development methodology.
...which is precisely the reason for my starting this thread.
> Paolo and I model application systems that are industrial
> strength with issues too complex for anyone to hold in
> their mind at one time. Development projects for
> industrial strength systems have high risks that justify
> DIM/CIM modeling and involve hundreds of use cases.
...and I congratulate you on your achievements, but what on earth does this have to do with the price of tea in China?
> I suggest that the risks associated with your CD Catalog
> application are too low for you to see the value of that
> which we are recommending for inclusion in your
> methodology.
...and I agree completely that the risks are too low. It's a simple project for crying out loud, and I made that clear from the beginning. My point is to begin by learning a subset of UML while working on a project of manageable size using Enterprise Architect. I already have the class model in mind, but I am forcing myself to start anew and incorporate the unified process methodology, using UML and EA. I've already seen clear advantages to doing so, which I would have missed had I simply used my existing methods. Is that not the nature of learning? I welcome mistakes as I delve into UML and design methodologies so that I may learn from them, and I don't care how many times I start my project from scratch. I have absolutely no problem discarding my work and starting fresh, so long as I learn from doing so. For example, I appreciate a response to this thread early on by "peter.zrnko", which led me to discard what I was doing and redesign that part of the use case model he addressed. Guess what, not only did it clear up my model, but it was eloquently simple and addressed my concerns beautifully. Mind you "peter.zrnko" is only a "full member" and not a "guru", so maybe that played a role in his clear and concisely targeted answer to my question, but I could be wrong.
So, while I appreciate the daunting issues facing "development projects for industrial strength systems", why mention this in the context my lowly simplistic single-user project? Do you want applause? Here, I'll salute you and give you a standing ovation. Then I'll turn around, nod my head from side to side, and walk away with a smile, realizing I have just wasted my time listening to a bloated windbag.
> I wish you well.
I doubt that...
> *POOF*
See what I mean? You've let out all the air...
-
Funny which people sometimes appear and disappear. If you're so thin-skinned you better should not expose yourself to a BB. Go and read a book.
My first and last post to this thread.
-
> Funny which people sometimes appear and disappear. If you're
> so thin-skinned you better should not expose yourself to a
> BB. Go and read a book.
>
> My first and last post to this thread.
Thank you for your brilliant insight. However, you have contributed nothing to this thread. (Is this a trend here, where "gurus" are self-important and say nothing meaningful?)
-
Still, I fail to see the reason why it is necessary to define classes at this stage of the game.
Just my opinion, but I actually think you could've started earlier with the classes. I would always start to build a domain model before writing use cases as a way of ensuring a consistent vocabulary. The classes in the domain model have very little to do with the classes in your C++ source files, but they are useful "nouns" to give context to all those "verbs" in the behavioural model. Don't worry that you might be committing to design decisions too early in the lifecycle - you aren't.
Have read of this: Section from book on Domain Modelling (http://www.craiglarman.com/book_applying/domain%20model%201.pdf) by Craig Larman.
-
Thank you for the reply.
> Have read of this: Section from book on Domain Modelling
> by Craig Larman.
Excellent. I am ALWAYS up to reading a good white paper, and I certainly appreciate your bringing it to my attention. Just a quick question about your opinion in starting earlier with classes. At what point would you begin class design; after the requirements model or elsewhere?
On a side note. I apologize for the bickering in this thread. I am here to learn, and I really do not respect the ivory tower arrogance of some in here. Yet, I believe they are the exception and not the rule. I trust I will learn from others, who are equally knowledgeable or even more so, and who will not be condescending. That is not to say that I will not learn from the arrogant ones, though it will require I separate the wheat from the irrelevant, tangential chaff; you know, the "stuff" that's said to self-promote and pat oneself on the back.
-
KP,
Once again, I want to thank you for your recommendation regarding domain modelling; it was VERY insiteful.
Important points:
1. Domain modelling is a subset of the Unified Process Business Object Model.
2. Domain modelling conceptualizes the system's features and requirements. Here's is where terminology has tripped me up in the past. I haven't seen it described this way, but that is essentially the concept. Instead, I've seen plenty of references to how domain modelling relates to business entities and business rules, even in the link you provided. However, Mr. Larman does an excellent job of clarifying this in terms understood by software developers.
3. In the unified process, implement domain modelling completely in the elaboration phase. The inception phase is suited for requirements modelling, which includes the system's use cases.
4. Avoid "analysis paralysis". Don't over-engineer the domain model, as this risks "design creep" in the elaboration phase. Domain modelling should be completed in a few hours once the requirements/features are well-understood, and it should not require very many iterations. Design should be relegated to the construction phase in UP.
Very cool indeed. This answers some of my questions. After reading Mr. Larman's work, I can safely say that I'm not too far off the mark yet. However, I will have to reconsider my current work on the project, and I will GLADLY do so. Happily, thanks to your referral, I've learned something.
My current work can be quickly summarized as follows:
1. Defined requirements (still needs work)
2. Established use cases that trace to the requirements
3. Created sequence diagrams for the use case scenarios
Based on the reading, a re-work should likely proceed as follows:
1. Define requirements
2. Establish use cases that trace to the requirements
3. Create a domain model
4. Create sequence diagrams for the use case scenarios
I suspect my sequence diagrams will change once I truly define the conceptual perspective of the system in the domain model.
Thanks again, KP.
-
I myself find I try to:
1. Understand the customer's Business Process currently and the need to for this "system". This helps me to capture both the "classes" from the business domain, and identify the use cases that trace to the proposed features of this system, and the business domain classes that those use cases make use of.. So in my mind, Business Domain Classes and Use Cases are developed iteratively together...
The BDCs help us establish that common business vocabulary (the things of the business) and the use cases the processes that the system will support (the how of the system, use within the business.)
2. Then once I have an understanding of this, the requirements (both functional and non-functional) will begin to be identified and specified. But without a UC and BDC model it is VERY difficult to SPECICFY requirements (I emphasize the word specify, because we are attempting to document the specification of the system, we are both talking about apples, not my apple, your orange.)
REMEMBER we NEVER have a full understanding of the customer’s requirements at any point in a project, as the requirements are continuously emerging and being clarified. This is where the ability to manage the requirement change is critical.
A SIDE note: PLEASE understand that it is EASY to be misunderstood in forum postings, and it is BEST to assume we are miss interpreting someone else's postings and are reading in attitudes, etc. I have found these individuals who have posted in response to your query, to be VERY helpful, and willing to take the time out of their professional life to help the EA community.
No one who posts here is required to share their knowledge, or to take the time to respond. They are doing it because they want to (for a variety of reasons), so give them the benefit of the doubt, and realize we all like to be appreciated when we give of our free time.
-
On the point of Extension Points vs. Generalizations, I think they both can be helpful, but I tend to prefer using generalization/specialization concept.
I often use a generalization to assist in the modeling, and then use a specialization of the use case, rather than having a large number of alternate scenarios.
Additionally, by keeping my use cases (when appropriate) in this style, my scenario numbers are reduced for a specific use case, more focused/specific to the use case, and I can then represent the scenario path/script using activity diagrams, which I find my customers is able to understand more clearly. Also since I use code to evaluate my activity diagrams (and generate a descriptive dialog that describes the interaction between the actor(s) and the system) I can then map these back to the UC's defined (Basic, Alternate, and Exception) scenario names.
-
bioform,
Thanks for your reply. Yes, your points make a good deal of sense, and they concur with the "Domain Models" PDF that KP, the administrator, recommended.
> A SIDE note...
I accept your constructive criticism; truly, I understand your point. However, I've been on enough forums to see the writing on the wall, and I will call a spade a spade.
-
bioform,
> I often use a generalization to assist in the modeling, and
> then use a specialization of the use case, rather than
> having a large number of alternate scenarios.
I may be wrong, but I think we are talking about two slightly different things. When "peter.zrnko" responded to my post, he advocated using <<include>> and <<extend>> stereotyped use cases as little as possible, and he stated his assertion was backed up in the UML literature. After I followed his suggestion, I reduced the spaghetti visuals that were developing in my use case diagrams. That also led me to re-evaluate each use case and its scenarios. Thus far, I have managed to reduce the number of scenarios to maximum of 3 (possibly 4) scenarios for any use case.
That said, I still have found use for what I believe you are stating. That is, I have instances of use cases that, in turn, are general use cases for specialized use cases.
Also, I still see the need for <<include>> and <<extend>> in my system, but I will use them sparingly - only when there is no other option.
Thanks again.
-
;D Or make us chuckle (clever asides that is)
You seem to be using use case's to describe a configuration (forms, mvc. and intend to use C++)....
Boundary, Control and Entity are objects... your just not naming or classifying them yet.
:P Kevin
-
> You seem to be using use case's to describe a configuration
You're right, and that is premature. I did have MVC in mind at the time, but I may rework my sequence models based on the domain model. In fact, this is brought up on the PDF described earlier in the thread.
-
;D Or make us chuckle (clever asides that is)
You seem to be using use case's to describe a configuration (forms, mvc. and intend to use C++)....
Boundary, Control and Entity are objects... your just not naming or classifying them yet.
:P Kevin
From what I have read, and practiced,during/after the modeling of the system using Use Cases and the Business Domain Model classes, the use of a Robustness Diagram (where you identify the Boundary, Control and Entity objects to check/verify if your model is sufficiently developed) helps bridge the gap between your analysis model and the preliminary design models. It is my understanding that these 'objects' are not the realizations of the use cases and BDM classes, but a way to validate that the analysis model is complete?
I good book that describes this process fairly well is "Agile Development with ICONIX process" by Doug Rosenberg, Matt Stephens, and Mark Collins-Cope. Apress is the publishers.
Good conversation on this thread...